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Proven Ferformance 



The BP-1200 is field upgradeable to 240 pins with full 
vector and continuity tests. With over 8,500 supported 
devices, you'll alv/ays be able to have the latest 
technology at your finger tips. 

The BP-1 200 outperforms its competitors in more 
ways than one. It's a proven fact. BP Microsystems 



has built the BP-1200 to program v/ith precision. Only 
a proven performer like the BP-1200 would offer a three 
year warranty and toll free technical support. And to top it 
off, BP Microsystems offers free software updates for the 
life of the programmer. Prove you're the best by using 
the best. The ffi>-l^S«ftjftlfn BP Microsystems. 
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68300 and ColdFire 

visionlCE: scalable hardware 
and real-time software debugging 
for this century and the next. 



Your next generation product will be smaller, faster, cheaper and out- 
the-door in record time. To survive, you'll need a state-of-the-art tool 
that's affordable for every developer on your team, yet doesn't run 
out of steam when really nasty bugs surface. You'll need visionlCE 
from EST. Its modular construction delivers the exact amount of 
power to conquer all your debugging tasks, today and in the future. 
With visionlCE, your tools are never underpowered, never overpriced. 

visionBDM 

Premium BDM emulation and control. It's all pu ami tia/r 
rock-solid software debugging. 

vision EVENT 

A full-scale ICE module to expose the toughest real-time bugs. 
It instantly adds 64K x 192 bit trace, 48 bit time stamp and 64 
hardware breakpoint on ranges, cSEtemals and mask values^ 

visionlMET 

Remote, shared debugging and high-speed download from 
anywhere on your LAN. 

visionMEIVi/visionFLASH 

4 IVIbytes of high-speed overlay memory and up to 32 Mbytes 
of NV memory for FLASH programming and production test. 

3rd Party Software 

Fully compatible with PassKey, pSOSystem, SingleStep, 
Tomado/VxWorks and XRAY/VRTX. 




800-957-5588 <in usa) \Ar\A/w.es'tc.ooim 

Embedded Support TqqIs Corp., 120 Royall St., Canton. MA 02021-9725, Tel.: 617-828-5588, Fax: 617-821-2268, European Tel.: 33-130-573200 
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Simulation ♦ On-Cfiip Debug ♦ Emulation ♦ Target Monitors and Servers 



Compilers 

♦ Diab Data 

♦ MetaWare 

♦ GNU - Cygnus 
Support 

♦ Microtec 

♦ SDS CrossCode 




SDS Graphical 
User Interface 
for Windows 
and UNIX 




Processors 

♦ 680x0 

♦ 683xx 

♦ PowerPC 

♦ Sxx 

♦ 6xx 

♦ Sxx 

♦ 4xx 

♦ ColdFire 



Both In-House RTOS 
and Commercial RTOS 



♦ Integrated Systems 

♦ Wind River Systems 

♦ Enea OSE Systems 

♦ Embedded System Prod 

♦ Precise Software Technologies 

♦ Accelerated Technology 

♦ KADAK Products 

♦ JMI Software Systems, Inc. 





Connections 



♦ Hewlett Packard 

♦ EST 

♦ Orion Instruments 



Pick the Best, SmoueStep Does the Rist. 

World-Class ♦ Open Environment ♦ For the Entire Life Cycle 

Now you can build your ideal toolset configuration for embedded development. From the components 
you select. From the vendors you choose. Rck your Ideal processor. The fastest compiler. Your favorite 
real-time kernel. In-house or proprietary. The best debugging tools. Assembled and working together with 
the latest hardware tools. Integrated with the SingleStep Debug Suite with a common GUI. The SingleStep 
Debug Toolset is the fastest way to get your next embedded design project up and running — and its open, 
modular design allows you to keep pace with the latest tools and most advanced proc^sors as they 
become available. Visit us on the Internet @ www.SDSI.com. 




software deve/opment systems 
The Most Responsive ^oftvyare Company 

815 COMMERCE DRIVE, SUITE 250, OAK Bm>OK, IL 60S21 PMONE 630.368.0400, FAX 630.990.4641. 

SingleStep is a tradema* of Software Development Systems, Inc. 

All otfier company and product names are trademarks or registered trademarks of the respective companies. 
© 1996 Software Development Systems, Inc. 
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ware co-simulation would help? These two engineers 
from Sandia Labs review and compare different mod- 
eling approaches you can take. 
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Understanding Universal Serial Bus 
Part 1 : USB Basics 



BY JOHN CANOSA. Connectivity is a big issue for 
embedded systems today, and the universal serial bus 
promises to simplify the process. This two-part series 
will take you into the xmderljmig layers of what USB 
tbchnology is all about. 



0Q State-Oriented Programming 



BY AL SCHNEIDER. Want to know how to allow 
sWlI microcontrollers to be fast, use very little memo- 
ry, and seem to do everything at once? This article 
details some ways of helping smaller chips live up to 
tkeir potential. 





special Report: 
#51 Software Debuggers 

BY NICHOLAS CRAVOTTA. 
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Draw on 

hardware-software 
co-simulation 
to speed your 
product to market. 

Coyer illustration by 
Rupert Adley. 
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Over two billion 68HC05 microcon- 
trollers are now in operation around the 
world. Powering an ever-growing range 
of consumei; industrial, computing, com- 
munications, and automotive products. 

Our 68HC05, the world's most 



popular MCU, is "customer-specified" 
for your system. In addition to the 150 
(and growing) types of 68HC05 MCUs, 
you can now select one of our fully 
upward object code compatible 
68HC08 microcontrollers. 



The 68HC08 Family offers even higher- 
performance with faster clock speed 
options and more features for your 
system design. But the 68HC08 doesn't 
just provide more instructions and regis- 
ters, it also runs 68HC05 object code. 



© 1 997 Motorola, Inc. Motorola and @ arc KgistHred ttademarks of Motorola, Inc. AH rights reserved. 
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The world's first choice. 



And both the 68HC05 and 68Ha)8 

Families offer complete support and a full 
suite of third-party development tools. 

So, if your system needs a "world- 
class" 8-bit solution, specify the world's 
first choice: Motorola. Our global 



manufacturing is already ramped-up 
to deliver production volumes 
anytime, anywhere. 

For more information on either the 
68HC05 or 68HC08 FamiUes, caU 
1-800-765-7795 ext. 882 or request 



by FAX at 1-800-765-9753. 

You may also visit our Web site at 

http://sps.motorola.com/csk. 

When it comes to 8 -bit solutions, 
there's a world of difference with 
Motorola MCUs. 



MOTOROLA 

CSIC Microcol^roller Divisions 

What you never thought possible^ 




Visit us on the World Wide Web 

http://www.keil.com/ 
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^ Embedded Software Development Tools 

•A' i^^> C167;C165, andC163 tntcr^rur^j^fomlyMf^the NEW! C161 



CI 66 Version 3.0 — The High-Performance C Compiler for the Siemens 166 Family 



Keil Development Tools unlock the 
features and perfornnance of the 
Siemens 166 and C167 and make you 
an Instant 16-blt embedded expert. 
The tjVision Windows-based IDE 
encapsulates your project with 
complete compiler and linker controls 
and helps you create complex 
programs in record time! The dScope 
symbolic, source-level debugger lets 
you simulate and debug your target 
system including external hardware. 



The ANSI-standard C166 c ompiler Is 
designed specifically for the 166 and 
CI 67 families— language extensions 
give you afecess to all CPU resources 
including the PEC, interrupts, SFRs, 
and DPPs. 

CI 66 is the most efficient, flexible 
development tool set available today. 
Support for all derivatives and 
compatibility with the major emulator 
vend ors makes CI 66 the best choice 
for your 166 and C167 projects! 



PK166/PK161 Highlights 



t/ ANSI-compliant C Compiler with C Libraries 

t/ Includes Memory Allocation Routines 

t/ Floating-Point Libraries Included 

✓ Support for Structures and Unions 

✓ Interrupt Functions may be written in C 

✓ Reentrant Functions 

✓ Parameters Passed in Registers 

i/ C Support for all Special Function Registers 

1/ Supports the Entire 16IVI Address Space 

^ Inline Assembly Code Support 

^ Includes Macro Assembler 

Includes Single-Chip Real-Time Operating System 

✓ Windows-based IDE and Debugger 

✓ Free Updates via the World Wide Web 

✓ Free Update Notification via E-mail 

✓ Free One-Year Technical Support 



dScope Source-Level, Symbolic Debugger and Target Monitor 



The dScope source-level, symbolic 
simulator/debugger helps you test and 
debug your 166 and CI 67 application 
programs. dScope provides: 

■ Execution, conditional, and 
memory access breakpoints, 

■ Watchpoints for all variable types, 

■ Mixed source/assembly display, 

■ Software performance analysis, 

■ Code coverage analysis, 

■ User and signal functions, 

■ and On-chip peripheral support. 



Debugging your target hardware is easy 
when you use the IVION166 monitor 
and dScope debugger. MON166lsa 
full-featured, royalty-free target monitor - 
designed for the 166 and CI 67 families. 
It can be configured for a wide variety of 
systems — even those with bootloader 
capabilities. Using dScope and 
MON166, you can easily view program 
source code, watch special variables, 
and examine target memory ! And, 
MONiee comes preconfigured for a 
variety of third-party evaluation boards. 




RTX166 — Real-Time Operating System 



dScope provides you with a powerful debuggingplatform that completely simulates atl 166 
and C167 derivatives Including the Cl65, C163, and C161 devices. Using GPU driver 
DLLs. dScope gives you dialog bat access to all on-chip SFRs. You can eaElly view and 
modify SFR contents tor A/D converters, timer/countefs, ports, and serial ports. 



Performance Comparison; 



RTX166 is a multitasking real-time 
operating system that supports the 
entire Siemens 1 66 and CI 67 family. 
RTX166 makes designing complex, 
time-critical software projects easy by 
providing sophisticated management for 
multiple tasks running on a single CPU. 

RTX166 Tiny supports single-chip 
applications where code and memory 
space must remain at a minimum. 
RTX166 Tiny lets you create and delete 
tasks and send and receive signals. 



RTX166 Full supports applications 
where robust features are required. In 
addition to the features found in the tiny 
RTX, the RTX166 Full version manages 
Interrupts, resources (via semaphores), 
and memory pools. Mailbox, system 
clock, and task management routines 
are also Included. 

RTX166 Full provides support for the 
C167CR CAN interface . This lets you 
get started with the CAN interface as 
quickly as possible. 



C167 C161 8051 
ZOMHl 16MHz 12MHz 

DhryMone Benchmarks 



C167 C161 
ZOMHi 16MHz 

Whetstone Bench 



Call 1-800-521-4957 for a FREE Evaluation CD-ROM of all our tools! 



United States: 
Keil Software, Inc. 

16990 Dallas Parkway, #120 
Dallas, Texas 75248-1903 
USA 

Phone 972-735-8052 
Fax 972-735-8055 
BBS 972-713-9883 
E-mail sales.us@keil,com 
support.us@keil.com 



Europe: 

Keil Elektronik GmbH 

Bretonisclier Ring 15 
85630 Grasbrunn 
Germany 

Phone -H-49 89 / 456040-0 
Fax +-1-49 89/ 468162 
BBS -1-1-49 89 / 4606286 
E-mail sales.intl@keil.com 
support.inti @ keil.com 



us Distributors: Celbo: 314-830-4084, CMX: 508-872-7675, Emulation Technology: 408-982-0660, 
HlTools (Hitex): 800-464-4839, l«letalinl<: 602-926-0797, Mlcom Systems: 214-245-2333, 
Microware Teclinology: 619-693-4280, Nohau: 408-866-1820, Peachtree Technology: 770-888-4002. 
Signum Systems: 805-371-4608. 

International Distributors: AUS: Electro Optics 02/9654 1373, A: Rel<irsch 01/259 72 70 0, 

B: Byteccm 010/22 34 55, Brazil: Anacom 11/453 5588, Canada: Ximetrix 905-602-8560, 

Czech: ComAp 2/6833 858, EDI 2/02 2683, CH: Thau 01/745 18 18, DK: Notiau 043/44 60 10, 

E: CAPEL 93/291 76 33/34, F: Aniycip 1/3961 1414, Hong Kong: Orilental 852/2402 3200, 

I: Microtasi< 02/4982051, Nord 02/66092,1, India: Embedded Systems Solutions 80/3323029, 

IRL: Astlling 061/33 44 66, Israel: ITEC 03/6 49 1202, Japan: NPS 03/3226 8110, 

Korea: Hankook 02/783 0022, Malaysia: Flasli 603/7168729. NL: Tritec 078/681 6133. 

NZ: Electro Optics 0800/44 2148, PL: WG 02/621 77 04, Romania: ASTI 3125907, 

S: Nohau 040/59 22 00, Singapore: Flasti 65/749 6168, Testech 65/7492162, SLO: ASYST 061/445526, 

S. Africa: EBE 012/803 7680/93, Kiberlab 012/660 2752, Taiwan: Deemax 3/5232548, 

Turkey: EMPA 1/599 30 50, UK: Hitex 01203/69 20 66, Nohau 01982/73 31 40. 
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World Enough and Time 

Several years ago, perhaps in the late '70s, a company embarked on the devel- 
opment of a turntable that could play vinyl records with a laser pickup. It had 
no needle to scratch the delicate vinyl; instead it read the grooves optically. 
Product development was plagued with glitches and cost overruns. I don't think 
this novel turntable ever made it to your local audio store, but it was a great idea 
right up to the very moment that compact disc players hit the market. Thereafter it 
sank like a stone into the slough of missed marketing opportunities. Herein lies the 
essence of the time-to-market issue. 

Cliche though it may be, you ignore time to market at your peril. According to 
a marketing guru (is that an oxymoron?), products that get to market six months 
late but on budget generate about 33% fewer profits over a five year span than they 
would have had the product shipped on schedule. Marketers have had drilled into 
them that 60% of a product's return comes within the first six mondis, which you'll 
lose if you're late to market. (Of course, this won't stop these same marketers from 
trying to get you to implement new features near the end of the development cycle, 
but that's another story.) 

It should be pretty straightforward to calculate the cost of the bill of materials 
and the related development costs, but once you factor in time to market, the entire 
equation can change. What if you spend more on your processor but get your prod- 
uct to market six months sooner? Your parts cost is higher but so are your revenues, 
at least theoretically. Money spent on development tools and methodologies are 
justified if they help get your product out the door faster. Programming in a high- 
level language vs. assembly language may produce less efficient code, but it 
increases productivity. The ability to reuse code can potentially reduce the devel- 
opment time and costs. Hardware/software co-design, the subject of this month's 
cover story, is emerging as a methodology that can help you to design and verify 
hardware and software in parallel and to accelerate product development. 

But while shipping your product sooner is a worthy goal, there are conditions. 
First, you have to determine when the product is ready to ship. It can be a terrible 
temptation to a cash-strapped company to ship before the product is ready, but it's 
no fair foisting alpha versions of your product onto imsuspecting customers. Jack 
Ganssle looks at this critical problem in his column this month. Racing to market 
can also be hazardous if you arrive too soon. Sometimes products ship before cus- 
tomers are ready to accept them. DVD may be an example. Some people fear that 
HDTV may potentially be another. It's instructive to note that a few companies 
have gone under, not because they failed to deliver their product, but because they 
delivered it before the market was ready for it. 

You won't run short of ways to spend money on product development. The 
tricky part is determining which ones will benefit you in the long run. Most frus- 
trating is that you'll never know for sure how you would have fared had you deliv- 
ered your product six months earlier or six months later You can only speculate. 
Of the many potential time-to-market tools, the one that would really help is a time 
machine. 
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We make your job easier by delivering 
much more than just pSOSystem™ — tlie 
industry's leading RTOS. The fact is we provide 
the greatesTweallfi' arid depth of tech- 
nology, tools and services in the embedded 
systems industry 

And as new technologies emerge, like 
Internet and Java™ you can be sure we're one 
step ahead. Because we're always looking 
at the big picture. 



Our range of solutions includes: 
RTOS 

pSOSystem™; Reliable, scalable RTOS, proven aeness the industr/s largest installed base. 
Tools 

pRISM+™: BDwerful, integrated graphical software development environment 
Network and Application Components 

Epilogue™: Industry's leading platform-independent protocol software. 
pSOSystem Components; Industry-specific application modules. 
Engineering Services 

Dr. Design: Foremost providers of innovative design solutions. 



1 integrated 
^S flj syste ms 

^fCZHr www.lsi.com 
goo. 543.7767 

Int^'ated Systems, Inc. 20 1 Moffett Park Drive, Sunnyvale, CA 94089 

pSOS is a regelered tjBdenwk and pSOSystem. pWSM+ and Epilogue are ti«^ 
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Reader Synchronization 



Policing 
Asynciironicity 

I'd like to make some comments about 
Bill Lamie's article "Multitasking 
Mysteries Revealed" (February 1997, 
p. 38). Not once was the term "asyn- 
chronicity" mentioned in the article. 
Sure, ease of development, portability, 
and maintainability are important fea- 
tures, but they can all be acheived to a 
high degree without a multitasking 
kernel. 

As to Lamie's explanation of 
responsiveness, throughput, and 
reduced overhead, one might think that 
the only alternative to using a multi- 
tasking kernel is to use polling! As we 
all know, this isn't the case — interrupts 
are used (maybe even to a larger 
extent) in non-multitasking systems. 
The only compelling reason to use a 
multitasking kernel is the temporal 
behavior of a system interacting with 
its envirormient, and more specifically 
the requirement that the system handle 
asynchronous events. Some systems 
that need to fulfill this requirement can 
get by with interrupt handlers and a 
control loop; however, interrupts have 
their own priorities, and large pieces of 
code in an interrupt handler will mask 
out lower priority interrupts, thus 
reducing overall performance. 

Furthermore, it is the asynchronous 
nature of a system interacting with its 
environment that should dictate the 
division of tiie software into tasks and, 
in most cases, will also dictate the rel- 
ative priorities between those tasks. 
Finally, only by adopting such a train 
of thought will developers manage to 
avoid the pitfalls of multitasking, such 
as starvation, priority inversion, and 
excessive overhead. Formal methods 
such as Temporal Logic offer a good 
^tart, but experience has taught me that 
a deep, understanding of the interaction 



The only reason to 
use a multitasking 
icernel is tiie 
temporal beiiavior 
of a system 
interacting with 
its environment. 

between asynchronous events (and not 
ordy the events themselves) will at 
most times suffice. 

G.C. Hillel 
ReTIC Systems Ltd. 
retic@trendline.co.il 

Author Bill Lamie responds: Upon 
further review of my article, I wish that 
I had addressed the proper use inter- 
rupts in embedded systems. It is cer- 
tainly true that asynchronous respon- 
siveness can be addressed solely with 
interrupts. However, this is typically 
only possible in small systems that 
have just one important interrupt. Even 
in such systems, a large interrupt han- 
dling routine might not be feasible if 
the underlying interrupt frequency is 
high. Furthermore, most processors 
have a single interrupt execution level 
(the Motorola 68K is an exception to 
the rule), which again restricts the 
applicability of this technique to small, 
somewhat single-purpose applications. 
Finally, tying an application's real- 
time capahilities exclusively to inter- 
rupt handling places the burden of 
processor allocation back in the appli- 
cation and increases processor depen- 



dence. All of this makes the application 
harder to maintain and to migrate to 
new processor families. 

As for not mentioning the term 
"asynchronicity, " I think the concept 
of trying to guarantee responsiveness 
to asynchronous external events was 
sufficiently addressed by my article. I 
concur that handling asynchronous 
system behavior is an important rea- 
son to use multitasking. However, an 
equally important feature of multitask- 
ing is that it facilitates the division of 
application software into components 
or objects. These components or 
objects are more easily reused, 
removed, added, and modified. As a 
result, the division of tasks should gen- 
erally be based on software compo- 
nents and their priorities should be 
selected such that they satisfy the sys- 
tem's real-time requirements. As my 
article mentions, care must be taken 
regarding how many tasks and priority 
levels are used. 

As for Temporal Logic, I don 't know 
how easily this formal method scales to 
larger, heterogeneous applications. It 
does seem as though it might be useful 
for state machines, and perhaps the 
logic inside of individual software 
components. 

.As my article pointed out, simple 
applications may not benefit from mul- 
titasking. However, applications that 
have multiple heterogeneous duties to 
perform, while at the same time han- 
dling asynchronous events in real time, 
could certainly make good use of a 
multitasking environment. 

Madness To His 
Methods? 

Generally speaking, I agree with Orv 
Balcom's ideas ui his article "Control 
Embedded Projects with Software 

f 
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Requirements Specs" (Febraary 1997, 
p. 52), but I do not agree with his 
methodology. 

Balcom points out many good ideas 
for what should be included in an SRS, 
but I take exception to a few parts. 
Balcom's development methodology 
describes the classic Waterfall devel- 
opment process, which has fallen 
under great scrutiny because it lacks 
the early feedback mechanisms that 
promote rapid product development 
and high customer acceptance. I'd like 
to comment on his model: 

1) The customer writes the Project 
Requirements Specification. I've been 
in this business too long to know that 
customers, be they internal or external, 
rarely have a clue what they want, let 
alone how to write it down in a clear, 
concise, and unambiguous way. I'd be 
more inclined to have a two-person 
team, one from the customer and one 
from the development team, write the 
document together. 

2) Design the program/write the SRS. 

3) Review the SRS. If it is wrong, go 
to Step 2. If the PRS is wrong, go to 
Step I. If the PRS is wrong at this 
stage, you have an expensive defect 
because the program is designed and 
the SRS is written. Perhaps a better 
Step 2 would have been to carefully 
review the PRS when it was complete, 
minimizing the errors coming into the 
Design/SRS stage. 

4) Code the program. 

5) Test the program. If code prob- 
lems return to Step 4, if design prob- 
lems return to Step 2, if PRS problems 
return to Step 1. Now you have really 
expensive PRS and SRS defects on 
your hands. You're at final acceptaiiee 
and the product doesn't meet the cus- 
tomer's expectations. 

In my opinion, a spiral development 
model would be better suited to this 
type of development. Get the customer 
to agree upon a core set of require- 
ments. Design and develop that core 
set of requirements, and show it to the 
customer early. Get the customer's 
feedback and specify the next set of 
deliverables. Of course, there is the 
risk that the customer will hate this 
early prototype, but it's better to find 
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mat out alter you nave spent Z3"/o oi 
the project budget rather than 90% (or 
worse yet, 150%). This also helps to 
focus the development team on provid- 
ing the requirements that the customer 
needs most, first. 

Likewise, using an ASCII editor for 
spec development is short sighted, as it 
doesn't allow the use of some of the 
modem Requirements Management 
tools which are now commonly avail- 
able. There is more than the SRS to 
controlling any project. What if you 
get to Step 5 and discover that the PRS 
is wrong? You must now update the 
PRS, SRS, design, test plans, test pro- 
cedures, and customer manuals. Do 
you have any method of assessing 
impact on those documents? With 
some of the modem tools, this is easy. 

A question that comes to mind is 
how widely accepted is a 120-page 
document? Do the developers all have 
a paper copy or do they access the doc- 
ument electronically? Paper copies are 
notoriously difficult to keep up-to- 
date. You specifically define many 
sections to your SRS; why not make 
each one of them a separate electronic 
document? You can link these together 
to create a master table of contents. I 
wotild stay away from paper copies 
and encourage the developers and cus- 
tomer to access them electronically as 
mWeh as possible. 

Requirements Management makes 
good business sense for everyone. 
Minimizing the amount of effort spent 
on Requirements Management and 
maximizing the benefit is where the 
piyoff is. 

Wayne Woodruff 
wayne@bmwmat.bucks.pa.us 

Author Orv Balcom responds: / feel 
Mr. Woodruff has confused the typical 
embedded system project with a data 
processing project. The embedded sys- 
tems projects with which I have been 
inyolved were based on specijic 
requirements, not "expectations" by 
the customer, who was usually not the 
end user. These resultant products 
would often be produced in hundreds 
or thousands and sometimes with mask 
programmed ROM. The projects were 



eitner jixea-price or naa a very con- 
strained budget. The incremental 
("spiral ") development of the product 
specification was not an option. In re- 
reading the articles on the Octopus 
Method (Awad, Kuusela, and Ziegler, 
September, October, and November, 
1996), I find that these authors also do 
not consider incremental development 
of the product requirements. 

This is because any significant 
change after the project has started is 
truly a change of scope and will 
require a modification of the budget 
and schedule. In most cases, it will also 
compromise the final product because 
of the attempts to minimize the impact 
of the new requirements. 

I am not familiar with the 
"Requirements Management" tools of 
which Mr. Woodruff speaks. My hunch 
is that if they are similar to some of the 
CASE tools described in the trade 
press, their cost would exceed the 
development cost of a typical 8-bit 
micro project. What I said in my article 
was that most word processors have 
proved inadequate. Large documents 
are not easily accepted by managers 
who don 't like to read or programmers 
who crave "creative freedom. " I have 
found that they are welcomed by 
mangers who want a definitive 
description (in a language they under- 
stand) of what the program is sup- 
posed to do. 

As to breaking the document into 
separate books, I much prefer one 
book with Post-its on the pages to 
which I am referring than half a dozen 
different books at my workstation. In 
no way can I imagine trying to write 
code or use an ICE with eight more 
pop-up windows with a sentence of 
spec each on my screen. Also, with 
individual documents, it is inevitable 
that someone will try to use books of 
differ.ent revisions. 
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Co-Simulating Software and 
Hardware in Embedded Systems 



Fighting time-to-market issues 
and wondering if hardware/soft- 
ware co-simulation would help? 
These two engineers from Sandia 
Labs review and compare differ- 
ent modeling approaches you can 
take and then describe how they 
addressed the problem. 




From the time of the first use 
of microprocessors and 
microcontrollers in embed- 
ded systems, software has 
been blamed for products 
being late to market. This stigma 
results from software being developed 
after hardware is fabricated. During 
the past few years, the use of hardware 
description (or design) languages 
(HDLs) and digital simulation have 
advanced to a point where the concur- 
rent development of software and 
hardware can be contemplated using 
simulation environments. This alterna- 
tive offers the potential of 50% or 
greater reductions in time-to-market 
for embedded systems. 

This article presents a tutorial on the 
technical issues that underlie hard- 
ware-software (hw/sw) co-simulation 
and the current state of the art. We 
review the traditional approach to 
sequential hw/sw design, and suggest a 
model for concurrent design, which is 
supported by co-simulation of software 
and hardware. We follow this discus- 
sion with sections on HDLs, modeling 
and simulation; hardware-assisted 
approaches to simulation; micro- 
processor modeling methods; brief 
descriptions of four commercial prod- 
ucts for hw/sw co-simulation; and a 
description of our own experiments to 
develop a co-simulation environment. 

TRADmONAL DEVELOPMENT CYCLE 

The workflow in a traditional 
embedded project is shown in 
Figure 1. Software is typically 
developed after a hardware design has 
begun to stabilize (some actually do!) 
and prototypes are available for inte- 
grating the software and hardware. 
Add to this the limited obsetvabMty of 
the operation of the hardware as the 
software executes, and the inability to 
control all of the elements of the 
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As per tradition, 
software still 
waits for liard- 
ware prototypes 
before significant 
progress is made 
on integration. 

design, especially peripheral compo- 
nents running synchronously from the 
microprocessor or microcontroller, it 
becomes obvious why the hw/sw inte- 
gration and test is the most time con- 
suming part of the project. (Almost all 
engineering veterans have at least one 
horror story of some heroic effort that 
involved sleeping under their desk.) 

Attempts at concurrent hardware 
and software development have result- 
ed in only a small portion of software 
bugs being found early. Software still 
waits for hardware prototypes before 
significant progress is made on inte- 
gration. So, hw/sw integration prob- 
lems are still found late in develop- 
ment and solved in software. 
Historically, the nature of technology 
has made this late discovery a fact of 
life. However, advances in hardware 
modeling and simulation offer the 
potential to develop a new design 
metiiodology using hw/sw co-design 
and co-simulation. 

CO-DESIGN AND C0-SIMUIA110N 

The process of concurrently 
developing hardware and soft- 
ware encompasses two main 
areas of study: co-design and co-simu- 
lation. In the context of this article, the 
term co-design refers to the process of 
translating the requirements for a 
desired system level flmctional behav- 
ior into a partition of hardware and 
software designs which, taken together, 



provide and maintain the desired sys- 
tem behavior. The term co-simulation 
is simulation of a model of the hard- 
ware runjiing the software, simultane- 
ously providing visibility (and control, 
to a lesser degree) of the hardware 
model while allowing software execu- 
tion to be controlled and observed at all 
levels of detail necessary for under- 
standing the behavior of the system. 

FIGURE 1 

Traditional embedded systems workflow. 
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The co-simulation environment should 
provide a user interface that is consis- 
tent with the current state-of-the-art for 
both the hardware simulators and the 
software emulators used by the devel- 
opment team. In an ideal world, this 
user interface would provide the same 
look and feel as the equipment used to 
test and verify the actual hardware after 
it has been produced. 
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Hardware/Software Co-Simulation 



FIGURE 2 

New model for concurrent software and hardware development. 
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A NEW MODEL FOR DEVELOPING 
EMBEDDED SYSTEMS 

Figure 2 shows an end-to-end 
development process using mod- 
eling and simulation. The sys- 
tem's functional requirements are 
specified as the inputs and outputs of a 
model and the restrictions on its imple- 
mentation. A behavioral model is 
developed to relate the inputs to the 
outputs. Simulations of the behavioral 
model are used to validate that the 
requirements are satisfied. The model 
becomes part of the specification, and 
simulating the model becomes the 
method for interpreting the specifica- 
tion. Then design of the hardware and 
software is much less likely to suffer 
the problems of misinterpretation of an 
English language description of that 
behavior. Maintaining the same behav- 
ioral description of the system 
throughout the development process — 
and filling in the details needed to 
achieve that behavior at each step in 
the design, cotipled with a co-design 



and co-simulation environment — 
allows designers to partition a system 
into smaller functional elements 
which, together, retain the overall 
behavior. Sub-system elements are 
each described by their own behavior, 
which is derived from the system-level 
behavioral model. 

This decomposition and stepwise 
refinement of the behavioral model of 
the- system and sub-systems (and sub- 
sub-systems) continues until the entire 
system is composed of fimctional ele- 
ments that are small enough that the 
detailed design of that element is 
straightforward. Part of this decompo- 
sition process also includes partition- 
ing fimctional elements into hardware 
and software components which pro- 
duce the desired behavior of the fimc- 
tional element. This hw/sw partitioning 
is carried out and determined based on 
traditional design tradeoffs such as 
performance, cost, volume, and so on. 

The co-simulation environment pro- 
vides the means to verify the behavior 



of each fimctional element composed 
of hardware and software. The behav- 
ior of elements implemented in hard- 
ware only is verified by hardware sim- 
ulation. In all cases, starting from the 
top level simulation and working 
down to each functional element of 
each sub-system, the behavior defined 
at each sub-system level is used to ver- 
ify the behavior of the lower level ele- 
ments making up that sub-system, and 
so on down to the simulation of the 
lowest functional elements. Hardware 
models used in co-simulation, while 
primarily behavioral models to main- 
tain simulation speed, are developed 
with the goal of synthesizing that 
model into silicon. Synthesis of the 
model (or verification of the model 
with an equivalent commercial part) 
and subsequent testing in the system 
allows the model to be fme timed, 
thereby improving the fidelity of the 
models used to perform simulations. 

Finally, by maintaining the behavior 
that was defined at the highest level of 
the system down through each subse- 
quent level, the fidelity of the product 
is ensured. That behavior can be used 
to establish the tests used for product 
acceptance. 

HOLS, MODELING, AND SIMULATION 

Modem digital design is often 
performed using hardware 
description languages such 
as VHDL (VHSIC hardware descrip- 
tion language) and Verilog HDL. 
Many textbooks about the VHDL and 
Verilog languages are available.' "2.3 
VHDL and Verilog are similar to pro- 
gramming languages, having their 
roots in Ada and C, respectively. 
(Software engineers should take great 
satisfaction in the observation that 
hardware design is reduced to pro- 
gramming.) In this section, we will 
touch on several subjects pertinent to 
hw/sw co-simulation, including the 
history of HDLs; how HDL models 
can describe circuits in different levels 
of detail to support hierarchical model- 
ing; schematic capttro from models; 
model verification; some different sim- 
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Hardware/Software Co-Simulation 



usniiGi 

The entity, generic, and port statements 
for an Intel 8051 microcontroller. 

enUty 8051 is 

neric (tval: 8051delays:=0ur.OI0S.cl€lays); 
|rt(ean, rst, xtaill, xtal2: IN st(l.loglc; 
S,psen: OUT std.logic; 

stdJji)gic.vector(7 DOOT 0); 
std.logic.vertor{7 DOWfTO 0); ^ 
p2: DIOUT std.logic_»ector(7 DOWNTO 0); 
p3: MOUT std.logic.vector(7 DOWKTO 0)); 
end 80S1; 




architecture RTL.HOOa of 8051 is 

code 
end RTL.I«)Oa; 

architecture BEHinQRIlLJIODEL of 8051 
code 

end BEHDVIORtL.KODEL; 



ulation methodologies; and model 
availability. 

VHDL is the older of the two HDLs 
and was originally developed in the 
DARPA Very High Speed Integrated 
Circuit (VHSIC) program as a means 
of providing precise descriptions of 
circuitry. As time went on, the HDLs 
were developed for purposes of model- 
ing, logic design, simulation of mod- 
els, and synthesis of circuitry from 
logic designs. HDLs are quite flexible 
and allow digital components to be 
represented at various levels of detail. 
An 8-bit adder, for example, might be 
described at a behavioral level using an 
algebraic expression, or it could be 
described using Boolean expressions. 
The behavioral description will be 
quite satisfactory for modeling and 
simulating many aspects of a system. 
However, the Boolean description is 
more readily synthesized into a circuit 
using an automatic synthesis tool. 

Synthesizing circuits fi-om the mod- 
els used to simulate the design is a very 
powerful design methodology because 
of the intimate tie between the model 



and the final circuit. The model 
becomes the circuit specification, and 
simulating the model becomes the 
method for interpreting the specifica- 
tion. Issues arising from a writer's and 
a reader's different interpretations of 
written language are obviated. Top- 
down design methodologies can begin 
with high-level behavioral models that 
are progressively synthesized into reg- 
ister transfer level (RTL) models and, 
finally, gate-level circuit layouts. 

The largest users of VHDL and 
Verilog are integrated circuit design- 
ers. ASICs and gate arrays are com- 
monly designed using these languages, 
and tools are available for synthesizing 
models into circuits or for automatical- 
ly routing connections in the gate 
arrays. For board-level design, VHDL 
seems to be the language of choice 
when an HDL is used. IC designers 
tend to use a different set of design 
tools and methodologies than do the IC 
users. 

A high level VHDL description of 
an Intel 805 1 microcontroller is given 
in Listing 1 . The top level of the design 
is the entity that contains an optional 
generic statement and a port statement. 
The entity's name is typically the name 
of a component. If used, the generic 
statement contains constants, such as 
setup times and delay times. The port 
describes the signals that are the inputs 
and outputs of the microcontroller. The 
port statement maps directly to the pins 
of the device being modeled. In this 
example, signals are a data type called 
standard logic, which can have nine 
different values, to account for the 
electrical properties of real signals. An 
architecture of the entity is where actu- 
al work is done on inputs to produce 
outputs. We show two different archi- 
tectures for the 805 1 . The first, called 
RTL.HODEL, is intended to contain a 
detailed model suitable for synthesis 
into an IC. The second, called BEHUV- 
lORAL.HODEL, produces the same behav- 
ior at the port, with a simpler internal 
representation. The architectures may 
be primitives that contain no lower 
level models themselves, or they may 



be constmcted out of lower level com- 
ponents, which are also entity-architec- 
ture pairs. 

The structure of the language lends 
itself well to schematic capture. A 
symbol for a component can be readily 
generated from an entity's port state- 
ment. The architecture of the entity can 
be associated with the symbol. 
Symbols are then linked together into a 
schematic drawing, compiled, and 
passed to a simulator. The same circuit 
can be simulated with different under- 
lying models by changing the architec- 
tures used for the symbols. 

To illustrate the difference in com- 
plexity between RTL and behavioral 
descriptions, consider how registers 
can be represented and incremented. 
An RTL description of an 8-bit register 
will be done using an entity-architec- 
ture pair. The register inputs are a data 
byte signal, clock and clear signals, 
and an output data byte signal. Their 
data type will be standard logic. 
Storing the signals will probably take 
18 bytes, one for each bit. In our 8051 
model, the architecture is about 15 
lines of code with loops, and quite a 
number of steps need to be performed 
to move data from the input to the out- 
put. To simulate incrementing the RTL 
register, its contents will be transferred 
to the accumulator, incremented, and 
written back to the register, taking hun- 
dreds of machine instructions. In con- 
trast, to represent the behavior of a reg- 
ister as seen from outside of the model, 
it is enough to have a one-byte variable 
that contains the register contents. 
Incrementing a register in a behavioral 
model may take only three instruc- 
tions: fetch to accumulator, increment, 
and store to register. This comparison 
makes several points for hw/sw co- 
simulation. First, an HDL model may 
be complex or simple. One needs to 
ask about the nature of the models 
being used. Second, the choice of 
model type can affect the execution 
time of a simulation by orders of mag- 
nitude. Third, one needs to be con- 
cemed with the fidelity of the model, 
such as how accurately the behavior of 
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FIGURE 3 

Elements of an embedded system in a co-simulation environment. 




a circuit will be modeled. Verifying 
fidelity of a behavioral model of a reg- 
ister to an RTL model should be trivial, 
but in more complicated examples, this 
verification becomes a difficult prob- 
lem in its own ri^t. 



Elementary logic primitives are 
available with most HDL sunulators. 
Models of common circuits in behav- 
ioral and synthesizable forms are avail- 
able from vendors. Behavioral HDL 
models of many ICs are commercially 



available from companies such as 
Logic Modeling. CAST, and Sand 
Microelectronics. Models of micro- 
processors are more difficult to obtain. 
Synthesizable models used by manu- 
facturers are, of course, valuable intel- 
lectual property. Some vendors sell 
only compiled versions of models. 
Working with a compiled version of a 
model limits your ability to see what is 
going on inside it, a potentially impor- 
tant part of debugging software in a 
virtual environment. The availability 
of models may influence how an appli- 
cation is modeled. 

HDL simulators are available from 
several vendors, including Synopsys, 
Viewlogic, Cadence, and Model 
Technology, but there are also two 
major simulation algorithms to choose 
from. Most HDL simulators on the 
market today are event-driven simula- 
tors. An event-driven simulator keeps 
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track of events happening at arbitrary 
times, which is necessary for simulat- 
ing asynchronous logic. Cycle-based 
simulators are just being introduced in 
the market. Cycle-based simulation 
requires all logic transitions to occur 
on clock cycle boundaries, such as in 
folly synchronous logic designs, dra- 
matically reducing the scheduling 
overhead. Simulation time is reduced 
by as much as 10 to 50 times for suit- 
able models. 

The execution time of simulations is 
important for hw/sw simulation. Our 
RTL model of the Intel 8051 executes 
about 10/xs of simulation time per sec- 
ond of real time using a Viewlogic 
simulator running on a Sun Ultra 2 
(I70MHz). In comparison, our behav- 
ioral model executes about 1.0ms sim- 
ulation time per second of real time 
(and could be five to 10 times faster). 
Before concentrating on tradeoffs for 



TABLE 1 

Speed and ease of use of processor models using simulation and emulation. 
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hw/sw simulation, it is worth briefly 
considering alternatives to software- 
based simulation. 

HARDWARE-ASSISTED MODB. 
SIMULATION 

Simulation time is an issue that is 
also faced by hardware designers 
who must verify the correctness 
of large designs. Hardware designs are 
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verified at the logic-gate level to the 
greatest extent possible. Verification of 
large gate-level designs can be 
addressed by hardware-assisted simu- 
lation and by logic emulation. 

In hardware-assisted simulation, a 
high-powered co-processor is used to 
execute the simulation of the gate-level 
model. Other parts of the simulation, 
such as peripheral circuits and test 
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benches, are left in the software simu- 
lator. Zycad is a major accelerator ven- 
dor that recently introduced a product 
called Lightspeed that executes about 
4,000 instructions per second for an 
80486-class processor, approximately 
a thousand times improvement over 
the speed of a software simulation. A 
Lightspeed accelerator will cost sever- 
al hundred thousand dollars. 



In logic emulation, the entire gate- 
level design is loaded into a matrix of 
programmable gate arrays. Quicktum 
is the largest vendor of this type of 
product. The major components of a 
"Quicktum box" are field-programma- 
ble gate arrays, the electronics to mon- 
itor the arrays, and the software to con- 
trol the system. The gate arrays can be 
clocked at 1 to 4MHz, so a model can 



be executed at speeds that are very fast 
compared to simulation, 1% to 10% of 
the fiiU design speed. Logic emulation 
is considered to be an important part of 
IC design verification.'' Maintaining 
and using an emulation system is also a 
substantial amount of work, and the 
price is in the himdreds of thousands of 
dollars.5 

Hardware modeling is a hybrid 
technique that runs software on a hard- 
ware processor which is interfaced to a 
software simulator which runs models 
of the peripheral circuitry. The speed 
of the entire simulation is controlled by 
either the software simulation or the 
communications overhead between the 
hardware processor and the simulator. 
Hardware modelers typically execute 
10 to 50 instructions per second.* 
However, the microprocessor is much 
easier to buy than the model the vendor 
wrote to design it! 

So, what is the message for hw/sw 
co-simulation? If your company's 
hardware design path uses accelerators 
or emulators, it will be valuable to 
debug software on these models, if you 
can attach a software debugger to 
them. If not, they are probably inap- 
propriate for hw/sw co-simulation 
because the accelerators and emulators 
work with gate-level models that take a 
lot of work to build and have more 
detail than necessary for most of the 
software development 

PROCESSOR MODELS 

Figure 3 shows the major ele- 
ments of a hw/sw co-simulation 
enviroimient. The environment 

is composed of software, a processor 
model with memory, and peripheral 
hardware. Note that most processor 
interactions will be with the program 
and data memory; at most, a few per- 
cent of its activity will be communica- 
tion with peripherals. The software is 
executed on a model of the processor 
in order to interact with the peripher- 
als. The software and hardware devel- 
opment tools allow the developers to 
view and control the simulation of the 
software and hardware models, 



WAS 



lYOUR LAST 

^mOKILl,? 




CARDtools, 
THE WORLD'S BEST EMBEDDED 
CO-DESIGN AND SIMULATION TOOLS. 

CARDtools' (Computer Aided Real-time Design tools) virtual 
I prototyping technology allows you to tackle design issues like: 

> Evaluating the best microprocessor type for your application 

• Understanding the impact of Real-time 
Operating Systems 

> Reviewing ASIC-vs-software tradeoffs 

• Reviewing architectural timing issues like: missed 
deadlines, starvation, and poor scheduling 

• Determining buffer memory needed 

> Considering a single chip solution 



101 Metro Drive, Suite 250 
San Jose California 95110 
Phone: 408.894.9500 
Fax: 408.894.9600 
E-mail: info@CARDtools.com 
www.cardtools.com 



I CARDtools 

systems 



WORLD'S aM*t REAL-TIME EMBEODED DBSIQH TOOL 



CIRCLE # 11 ON READER SERVICE CARD 



JUNE 1997 




Hitachi ICs bring 

your biggest 



ideas aown to sizF. 



SuperH 

Rise engine 




IC solutions 
for the hottest 
applications from 
2-ivay wireless 
paging to 
ndows* CE 
4held PCs. 



These days, the biggest ideas in con- 
sumer electronics are all about the same 
size: Handheld. They're now the "Wow" 
of Wall Street; the "Egad" of editors. And 
they're the electronics industry offering a 
hand to millions who have not yet "gone 
digital." For OEMs of successfid Personal 
Access products, their ever-increasing 
integration within the size, power and 
cost constraints of handheld systems is 
good reason to shake hands with Hitachi. 

How to get bigger, better, smarter, 
smaller. Thanks to Hitachi's ability to 
combine its best-selling line of MPUs, 
M(3Us and advanced memory devices, 
and deliver these as integrated solutions, 



we have become the leading IC supplier 
for handheld systems. In fact, Hitachi's 
SuperH RISC Engine is die processor of 
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the new Windows CE Handheld KDs. 

Hitachi helps you hit the small 
time. To learn how you can get small 
fast, phone 1-800-446-8341, ext. 800. Or 
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Depending upon the models chosen, 
the processor and memory may or may 
not have internal states visible from the 
outside. The method of modeling the 
processor and its interaction with 
memory is one of the most important 
choices to be made. As one considers 
the choices, the 20-80 rule (20% of the 
effort yields 80% of the results) should 
be kept in mind, and balanced against 
the possibility that a serious error will 
be missed. Table 1 shows the execu- 
tion speed and ease of use for various 
combinations of emulation methods 
and processor models and simulation. 

The tradeoffs to be evaluated in this 
choice are between model and timing 
accuracy; visibility of the internal state 
of the processor and peripheral models 
for debugging purposes; model avail- 
ability; and simulation speed.' How 
you make tradeoffs depends upon 
where you are in the design process 



The method of 
modeling the 
processor and its 
interaction with 
memory is one of 
the most 

important choices 
to be made. 

and the type of design (board vs. 
ASIC) you are using. Modeling and 

co-simulation can be used early in a 
design to evaluate software-hardware 



tradeoffs that will affect the hardware 
design — a co-design activity by our 
definition. For example, early in a 
design, the required processing power 
must be established. Later in a design, 
the processor is fixed, and you may be 
doing the software-hardware integra- 
tion in advance of receiving a proto- 
type, what we defined as co-simula- 
tion. The objective of the modeling and 
the types of models that are available 
for the hardware simulation also 
depend on whether the design is of a 
board-level system built with commer- 
cial ICs, a board with a commercial 
processor and custom ASICs for 
peripherals, or a fully custom ASIC 
with an embedded processor core. Re- 
work costs become progressively larg- 
er with these three options. 

At the co-design level, high-level 
models that run high-level code with- 
out showing internal details of proces- 
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FIGURE 4 

Co-simulation environment constructed from commercial, off-the-shelf tools. 
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sor operation may be satisfactory. 
Some provision needs to be made for 
the occasional interaction with the 
peripherals. For board-level design 
with discrete ICs, you will probably 
find only behavioral models of the 
processor and the peripherals. If you 
use custom ASICs, you may have 
access to the RTL models used to 
design them. After receipt of a board- 
level prototype, you will still have 
good visibility of the interconnections 
between the processor and the periph- 
erals, so that conventional methods can 
still be used for final integration. For 
an ASIC with an embedded processor, 
models may be available down to the 
RTL level for the entire design. In this 
case in particular, detailed models may 
be desirable for portions of the hw/sw 
integration because it will be the only 
prototype available before a very 
expensive and time-consimiing ASIC 
tum. Even after the ASIC is fabricated, 
you will have little visibility into it for 
debugging; the software and hardware 



viewers may need to be your in-circuit 
emulator and logic analyzer. RTL 
processor models give the best accura- 
cy and internal visibility, but they are 
difficult to obtain. If the processor and 
peripherals are asynchronous, event- 
driven simulation is required to repre- 
sent their interactions exactly, and only 
a few instructions per second will be 
executed. At the cost of only evaluat- 
ing the simulation at clock-cycle 
boundaries, a cycle-based simulator 
increases speed to about 100 instruc- 
tions per second. The value of using an 
RTL model is that it will have nearly 
absolute fidelity with the hardware 
synthesized fi^om it. 

Simplified processor models may be 
acceptable to the software developer. 
Instruction set simulator (ISS) models 
of processors are commonly included 
in software development environ- 
ments. An ISS model includes the 
internal registers and memory, 
although it probably assumes sequen- 
tial execution of the instructions, aii 



assumption that may not be satisfied 
for pipelined processors. An ISS can 
be written in an HDL and be executed 
by the HDL simulator with the periph- 
eral models. Execution speeds can be 
increased to the 2,000 to 20,000 
instructions per second range. An ISS 
can also be written in a conventional 
programming language and executed 
in a process separate ft-om the HDL 
simulator if there are means for syn- 
chronization and communication. An 
ISS model keeps track of execution 
time pretty well, and it can be used to 
generate many of liie bus-cycles pro- 
duced by a real processor. For a soft- 
ware developer, an ISS can provide 
most of the processor functionality 
while having a very realistic connec- 
tion to the peripherals. A disadvantage 
of ISS models, as with any behavioral 
model, is that fidelity to the actual 
hardware may be poorly understood. 

An ISS is useful for software inte- 
gration relatively late in a project, but 
it may also be used for system behav- 
ioral modeling earlier in the design. In 
conjunction with behavioral models of 
peripherals it can be used to help eval- 
uate processor requirements, hw/sw 
tradeoffs, and validate system confor- 
mance to requirements, before pro- 
ceeding with detailed design. 

Further simplifications are possible 
as well. The apphcation software could 
be a program written in a high-level 
language, executing on a workstation 
in the workstation's native machine 
language, communicating with the 
hardware simulation by special func- 
tion calls.8 Synchronizing the software 
execution with the simulation of the 
peripheral hardware will be imperfect, 
but perfect synchronization may not be 
necessary. 

CO-SIMUIATION PRODUCTS 

Tools and environments for really 
doing hw/sw co-simulation 
began to appear in 1995. An 
effective environment must tie togeth- 
er tools familiar to both the software 
and hardware engineers. This environ- 
ment is difficult to produce because of 
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HGURE 5 

Intel 8051 initializes and handles communication between Intel 82527 CAN contrails. 
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the many tradeoffs to be made, and no 
single right way accomplishes the task. 
We are aware of four companies that 
provide capabilities for hw/sw co-sim- 
ulation. In this section, we give brief 
descriptions of their products, as we 
understand diem. 

HMHI-LEVB. MODEIJIIG: 
EAGLE DESIGN AlfTOIVIATION 

Eagle Design Automation offers 
two products that address sw- 
hw co-simulation: Eagle! and 
Eagle V.'-l"'!' Both are relatively high- 
level modeling tools, with two major 
components. The first is the Virtual 
Software Processor (VSP), and the sec- 
ond is flie Virtual Piodact Console 
(VPC). 

The Virtual Software Processor exe- 
cutes high-level language code com- 
piled into the native machine language 
of the workstation. The only internal 
behavior of the target processor and its 
memory that is modeled is the part that 
handles interactions with external 
devices, such as I/O ports. High-level 
language function calls communicate 
through these ports with the peripheral 
device models that are executed by an 
HDL simulator. The strengths of this 
method are the simplicity of the model 
and rapid execution speed (it is capable 
of running at 5,000 instructions per 
second). The method has some weak- 
nesses: model verification is difficult 
because the models are far-removed 
from the detailed behavior of the target 
processor and execution of the soft- 
ware and the hardware simulation are 
difficult to synchronize. Three meth- 
ods are used for synchronizing the 



VSP with the HDL simulator. 12 The 
fnst is Polled Status synchronization in 
which a hardware action is initiated by 
the software, which then polls a status 
register until a flag is set signifying 
that the hardware action is complete. 
The VSP can also respond to "hard- 
ware" driven interrupts much as a 
hardware processor would respond. 
The third way is for the software to 
estimate how long a simulation of a 
hardware action will take. 

The Virtual Product Console links 
together the software development 
enviroimient, the VSP, &e hardware 
simulator, and its development envi- 
ronment. Commercial software devel- 
opment tools are supported by the 
VPC. The VPC connects the VSP to 
VHDL and Verilog simulators from 
most of the major CAE vendors. One 
of the virtues of Eaglel is that it should 
fit into many existing design environ- 
ments. Another interesting feature is 
that the VPC can link multiple proces- 
sor models to the HDL simulator. 

In their Eagle Design Application 
Note, "An Evolution in System 
Design," G. Zach and J. Wilson 
describe use of an Eaglel prototype in 
the design of a complex ASIC.'^ Three 
serious errors were caught in simula- 
tion which would have resulted in 
ASIC redesign and re-spin. 

VIRTUAL ICE: 

YOKOGAWA ELECTRIC CORP. 

Yokogawa offers products 
called Virtual ICE and 
VMlink.i3 Virtual ICE pro- 
vides an in-circuit emulator environ- 
ment for code development on HDL 



models. Conceptually, it plugs into an 
HDL model of an application (ASIC or 
board) in the same way that a hardware 
ICE plugs into a processor socket in a 
circuit board. VMlink is an interface 
for connecting to the MATLAB simu- 
lator. MATLAB is a more general 
modeling tool, so that the simulation of 
a digital application can be coupled to 
a simulation of its surroundings. For 
example, a motor controller model can 
be connected to a motor model. This 
tool looks very usefiil if it will fit into 
your design environment.''' 

Virtual ICE consists of a processor 
model and an ICE interface to the 
processor. The processor model is a 
bus-cycle-accurate ISS written in 
Verilog. Yokogawa' s method for 
model verification is not disclosed. 
The present version of Virtual ICE can 
be run using the Verilog-XL and VCS 
Verilog simulators. Future versions of 
Virtual ICE will run under "bilingual" 
simulators that will accept designs 
with a mix of VHDL and Verilog com- 
ponents. Off-the-shelf processor model 
offerings are somewhat limited, but 
custom models are available. The 
Verilog language includes a program- 
ming language interface, which is used 
to connect to ICE software. The ICE 
software provides windows for source 
code, tracking assembly language, 
intemal registers, memory, and break- 
points. Execution of the model is con- 
trolled using the ICE interface. We 
have seen little emphasis on visibility 
into the hardware side of the design, 
but presumably there is some access 
through the Verilog simulator. 

SYSTEM LAR AND REHAVIORAL 
VERIFICATION TECHNOLOGY: 
CPUIECHNOLOGY 

CPU Technology's main busi- 
ness is design of custom micro- 
processors, for which they 
have developed their own design 
methodology and proprietary tools. 
The design of MIPS quad-^BCessor 
systems with this approach appears to 
be one of the most advanced top-down 
design methodologies in use today.i^ 
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They offer two products, SystemLab 
and Behavioral Verification 
Technology (BVT), but CPU 
Technology does not make their lan- 
guage or simulators available for sale. 
What they do offer is a modeling ser- 
vice that provides their customer a 
model and the environment for work- 
ing with it. They work with customers 
to take models to silicon. 

SystemLab is an environment for 
developing behavioral models of sys- 
tems and their components. Models of 
processors and peripherals are con- 
structed using CPU Technology 
Design Language, a proprietary HDL. 
The models are executed using a pro- 
prietary cycle-based simulator. Their 
design approach is to design the func- 
tionality of all system components at 
this behavioral level before going to 
detail design of the components them- 
selves. Very high visibility into 
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designs is available using virtual 
instruments such as logic analyzers 
and oscilloscopes. The microprocessor 
models run real code and contain rep- 
resentations of all intemal registers. 
They have models of x86, Motorola 
68000, MIPS, and various DSP proces- 
sors. A unique feature of their simula- 
tor is that it will run backwards, so 
once a problem is observed, it's easy to 
back up a few cycles to examine what 
went wrong rather than re-starting the 
simulation. SystemLab models can be 
further synthesized into circuitry 
through a path using Verilog and 
Synopsys sjmthesis tools. Verifying 
model fidelity to the fmal circuit with 
this design path is relatively straight- 
forward. However, when the method- 
ology is applied to model existing 
components, model verification 
becomes a critical issue. 

BVT is CPU Technology's method 



for verifying the accuracy of models. It 
is a semi-automated method for gener- 
ating extremely comprehensive sets of 
test vectors which can run on behav- 
ioral models, gate-level models, or real 
hardware. Quantitative measurements 
are made of the behavioral model 
fidelity to the gate-level model or hard- 
ware. We were quoted a price for BVT 
test modules for a model of a small 
system that appeared to be 20 to 30 
times greater than the price of the 
model. This price disparity highlights 
the difficulty of comprehensive verifi- 
catimi of behavioral models. 

CO-VERIFICATION ENVIRONMEIIT: 
MENTOR GRAPHICS AND 
MICROTEC RESEARCH 

Mentor Graphics and Microtec 
Research merged in 1995 in 
order to link software and 
hardware development products. They 
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FIGURE 6 

EMME's view of the VHDL model's operation with SGII and Viewsim. 
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have recently announced a product 
called Seamless Co- Verification 
Environment (Seamless CVE).i6,i7 

Seamless CVE combines the 
Microtec X-Ray software development 
environment wilh Mentor Graphics' 
HDL simulation. Microtec has provid- 
ed instruction set simulators for many 
processors for some time. Standalone 
execution speeds of up to 100,000 
assembly instructions per second are 
quoted for the ISS models. Seamless 
CVE is an interface between the ISS 
model and the HDL simulator that exe- 
cutes models of the peripheral devices. 
The interface functions include syn- 
chronization of the ISS with the HDL 
simulator, memory management func- 
tions, and transferring information 



between the ISS and HDL processes. 
Seamless CVE allows its user to take 
advantage of the observations that 
most CPU activity is with memory, 
and that less than 1% of the instruc- 
tions communicate with peripherals. 
The architecture of CVE allows the 
user to run memory models in the HDL 
simulation, or in the CVE. They quote 
execution of 450 instructions per sec- 
ond with memory fetches from the 
HDL simulation. CVE allows the user 
to choose (dynamically during execu- 
tion) various levels of filtering of the 
transactions between the ISS and the 
HDL simulation. The first filter is 
instruction fetch masking. Additional 
clock signals can be suppressed by the 
user when he knows that there is no 



processor-peripheral interaction taking 
place. With full filtering, execution 
may speed up to as much as 15,000 
instructions per second. This method- 
ology should give good timing fidelity. 
The fidelity of the ISS to a real proces- 
sor should still be verified. 

EMBEDDED MICROPROCESSOR 
MODELING ENVIRONMENT (EMME) 

We have been experimenting 
with ways to provide a co- 
simulation environment 
using commercial off-the-shelf tools 
for over a year. We thought this was an 
important capability that would short- 
en our development cycle; improve the 
integrity, reliability, safety and securi- 
ty of our systems; and provide an 
excellent spring board to the next 
major hurdle, a co-design environ- 
ment. Although when we began, no 
tools were available, several have 
become available since then. Coupling 
commercially available tools allowed 
us to take advantage of each tool's 
strengths, providing a kind of syner- 
gism not typically foimd in a single 
vendor solution to a multi-discipline 
problem. This gave us the greatest 
flexibility to configure the co-simula- 
tion environment, allowing us to 
decide what level of detail is needed 
based on which stage of the develop- 
ment cycle we are in. 

Figure 4 shows the Embedded 
Microprocessor Modeling Environ- 
ment (EMME) we developed at 
Sandia. There are four software com- 
ponents running on two workstations 
on a network. The computer in the 
lower left of the figure displays the 
GUIs for the hardware and software 
and the computer in the upper right is 
a fast, high powered workstation run- 
ning the VHDL simulator. All of the 
elements will run on a single worksta- 
tion without modifications, or, as 
shown, coupled across a network, 
allowing additional computing power 
to be utilized. The first component is a 
software debugging tool called 
SourceGate n (SG2) from Huntsville 
Microsystems, Inc., which is the GUI 
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for their in-circuit emulators (ICE). 
The second component is the 
Powerview framework from 
ViewLogic Systems, Inc. We use the 
Viewsim VHDL simulator and the 
Viewtrace waveform viewer for real- 
time display of hardware signals, and 
we use other tools for schematic cap- 
ture and model compilation. The third 
component is oiir command translator, 
Vemulator. The foiirth software com- 
ponent is a VHDL model of an Intel 
805 1 , for which we used two different 
models. We used both a synthesizable 
RTL model from Sandia's digital 
ASICs department and an instruction 
set simulator written in VHDL by 
Gary McGovney. 

Our work centered on Vemulator, 
which executes on the same worksta- 
tion as Viewsim. Vemulator starts and 
initializes Viewsim, Viewtrace, and 
the VHDL models. Vemulator is a 
server for SG n, accepting ICE com- 
mands, translating them into Viewsim 
commands, gathering the results of the 
simulation from Viewsim, and retom- 
ing a response to SG II. 

We applied EMME to a simple cir- 
cuit shown in Figure 5. The 8051 runs 
a program which initializes the two 
Intel 82527 CAN controllers, and then 
controls the exchange of messages 
between them. Figure 6 shows 
EMME's view of the VHDL model's 
operation with SG II and Viewsim. 
The upper windows are SG II win- 
dows showing the C main program, a 
C subroutine, assembly code, a com- 
mand window that was used to single 
step assembly code, memory, and reg- 
ister maps. A Viewsim window at the 
bottom shows 6ms of simulation time 
during which the CANs were initial- 
ized and exchanged two message 
packets. There are four signals 
between the circuit components, as 
well as three signals internal to the 
CAN controllers. It is more than a 
conventional software simulation 
view because the user can observe any 
hardware signal through the Viewsim 
window, even internal signals which 
would not even be visible in actual 



hardware. This enormous increase in 
signal visibility, before building a 
prototype, is where co-simulation 
offers an advance over older design 
methods. 

This simulation took about 10 min- 
utes of actual time to execute. Of this, 
about six seconds were used to execute 
the ISS processor model. Adding the 
two CAN controller models to the cir- 
cuit slowed execution by almost 30 
times. Displaying 33 signals (only 
seven are shown) in Viewtrace as they 
were generated slowed the simulation 
by another four times. Using the RTL 
8051 model only slowed the simula- 
tion another 30%, although it is 100 
times slower than the ISS model. An 
important point to remember when 
evaluating products on the market is 
tiiat even with a fast, simple processor 
model, executing peripheral logic 
models (your design that you really 
care about) and display software may 
very well be your real source of perfor- 
mance limits. 

We think this approach is valuable 
because, for the price of writing the 
translator program (less than 10,000 
lines of code), we retained the devel- 
opment environment already familiar 
to software and hardware engineers 
and added powerful new capabilities 
while maintaining flexibility. 
Developing Vemulator allowed us to 
couple a tool used by software devel- 
opers for hw/sw integration to the 
hardware simulation environment 
used by our hardware designers. This 
allows the two sides to work concur- 
rently while keeping their accustomed 
development enviromnents. Existing 
tool knowledge and experience is 
maintained throughout the develop- 
ment process and training for similar 
tools used at different stages is kept to 
a minimum. An even more important 
advantage to us is the ability to 
change the level of detail contained in 
the hardware models at various stages 
in the development process. At the 
front end of the development effort, 
fairly simple behavioral models and 
an ISS (written in VHDL) for the 



processor can be used to define the 
system level behaviors. Later, when 
more deMled design information is 
available, simpler models can be 
replaced by the more detailed models, 
allowing the checkout of critical inter- 
faces and high consequence elements 
of the system like security critical 
functions. The design team, rather 
than the tool, is allowed to make the 
decision as to the amount of detail 
necessary. 

INCREASING CONCURRENCY 

The key to reducing flie time to 
market for embedded processor 
systems is to adopt development 
methodologies that greatly increase flie 
degree of concurrency of software and 
hardware development. We see hw/sw 
co-design and co-simulation as two 
elements of the new paradigms. The 
technology of hardware modeling and 
simulation has advanced to a stage at 
which software can be sensibly devel- 
oped on models of hardware, the co- 
simulation part of a new paradigm. A 
key to successful modeling and simu- 
lation is to make models with no more 
detail than necessary and to choose an 
appropriate simulation method. Many 
ways exist to construct sw-hw simula- 
tion environments. The trick will be to 
identify methods that will improve 
productivity at your company. Mi^i 

We wish to thank Huntsville 
Microsystems for their assistance with 
interpreting SourceGate II commands, 
Viewlogic Inc. for help with coupling 
to the Powerview environment, 
Sandia's Digital ASICs Department 
for providing the RTL model of the 
8051, Gary McGovney for the ISS 
model of the 8051, and Dale Brandt for 
the code in the CAN controller demon- 
stration. We also had valuable demon- 
strations and conversations with rep- 
resentatives of Eagle Design, 
Yokogawa Electric, Mentor Graphics 
and CPU Technology. This work was 
supported by the U.S. Department of 
Energy under contract DE-AC04- 
94AL85000. 
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Understanding 
Universal Serial Bus 
Part 1 : USB Basics 

Connectivity is a big issue for 
embedded systems today, and the 
universal serial bus promises to 
simplify the process. This two- 
part series will take you into the 
underlying layers of what USB 
technology is all about. 



Today's embedded systems 
designers are finding tiiat 
more and more of the 
products they are design- 
ing are not isolated stand- 
alone devices. We are in the informa- 
tion age, but information is only valu- 
able when it can be accessed and uti- 
lized. Connectivity is a key issue for 
embedded systems today. Being able 
to connect and share information with 
a PC-oriented world is of paramoimt 
importance. One of the key mecha- 
nisms for cormecting to PCs and, most 
likely, workstations and Macintoshes, 
will be the universal serial bus (USB). 

USB is a peripheral bus standard 
developed by PC and telecom industry 
leaders — Compaq, DEC, IBM, Intel, 
Microsoft, NEC, and Northern 
I Telecom — ^that will bring the plug- 
I and-play of computer peripherals ont- 
^ side the box, eliminating the need to 
^ install cards into dedicated computer 
^ slots and reconfigure the system. 



Personal computers equipped with 
USB will allow computer peripherals 
to be automatically configured as soon 
as they are physically attached — with- 
out the need to reboot or run setup rou- 
tines. USB will also allow multiple 
devices (up to 127) to run simultane- 
ously on a computer, with peripherals 
such as monitors and keyboards acting 
as additional plug-in sites, or hubs. 

The motivation for developing USB 
was originally as a computer telephony 
connection mechanism. As the specifi- 
cation developed, it became obvious 
that it was much more universal than 
for just one application. USB was 
designed for ease of use, incorporating 
both hot plugging and software plug- 
and-play mechanisms. It also was 
designed to allow for easy expansion. 
USB is a low- to mid-speed serial com- 
munications bus that operates at 
12Mbps, with a 1.5Mbps sub-channel 
for cost sensitive applications. Many 
people see USB as a competitor to 
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another serial bus, IEEE 1394 
(Firewire). This really is not the case: 
the two buses are complementary, with 
USB occupying the low- to mid-speed 
range, while 1394 is targeted toward 
high-speed applications. Figure 1 illus- 
trates the complementary nature of the 
two buses. 

This two-part article investigates 
USB from the perspective of an 
embedded systems developer design- 
ing a device that acts like a USB slave. 
This part contains an introduction to 

FIGURE 1 

USB and IEEE 1394 focus areas. 



USB, concentrating on the peripheral 
side of the specification. The second 
part will contain an overview of some 
of the USB controllers that are avail- 
able, as well as discuss some imple- 
mentation issues regarding bandwidth 
and throughput. 

The USB specification describes the 
mechanical and electrical attributes of 
the bus, the protocol, the different 
types of bus transactions, bus manage- 
ment issues, and the upper level pro- 
gramming interface. It is defmed to be 
truly an open standard, so that devices 
from different vendors will interoper- 
ate without any help fi-om the end user. 

The following sections of this article 
will examine the protocol, the four 
types of bus transactions, and the pro- 
gramming interface, as well as a brief 
introduction to the physical layer. 

USB ARCHITECTURE 

USB is a master/slave type bus. 
In USB parlance, a host is 
responsible for performing the 
scheduling of the bus, and various 
devices, which can be either hubs or 
functions that share the serial data 
stream. The actual physical topology 
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HGURE 2 

Physical hardware view. 
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FIGURE 3 

Logical hardware connection. 
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of the bus is best described as a tiered 
star network as shown in Figure 2. 

All devices are connected over a 4- 
wire cable, no longer than five meters. 
Two of the wires are twisted pair car- 
rying differential data, while the other 
pair of wires provides a limited amount 
of power so that devices may be pow- 
ered off the bus itself. Data is trans- 
ferred using non-return to zero invert- 
ed (NRZI) encoding at 12Mbps. There 
is also a 1 .5Mbps sub-channel that can 
be simultaneously supported on the 
same wire as the 12Mbps channel. 
Each device must plug into a special 
type of USB device called a hub. 

Hubs are intelligent devices that not 
only act as signal repeaters and routers, 
but also provide some basic power 
management. Hubs are essential to the 
plug-and-play implementation. Each 
hub has the ability to control the power 
applied to devices connected down- 
stream from it, as well as notifying the 
host when a device has been connected 
or disconnected from the network. 
Once a device is connected to the net- 
work and completes the enimieration 
process (plug-and-play discovery), the 
hubs act as repeaters and become trans- 
parent from a data flow perspective. 
This is shown in Figure 3. 

USB PROTOCOL: PACKET TYPES 

All USB bus fransactions 
involve transmissions of one to 
three packets. Each transaction 
is initiated by the host. There are four 
types of USB packets: token, data, 
handshake, and special. 

All transactions start with a token 
pacMt, which the host sends out on a 
regularly scheduled basis. The token 
packet consists of information describ- 
ing the type and direction of the trans- 
action, as well as addressing informa- 
tion so that the correct USB device and 
device function receives the packet. 
Note that token packets are broadcast, 
meaning they are received by all 
devices connected to the network that 
support the bit rate at which the token 
packet is transmitted. 
As shown in Figure 4, each token 
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FIGURE 4 

Token packet fields. 
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packet consists of an 8-bit packet iden- 
tifier (PID) field tiiat currently have 
any one of the following: 

■ IN: signifying a read fi-om a device 

■ OUT: signifying a write to a device 

■ SOF: indicating the start of a USB 
frame 

■ SETUP: indicating that a 
command/control data packet will 
be forthcoming and cannot be 
ignored 

The address field follows the PID. It 
is a 7-bit field, which effectively limits 

FIGURE 6 

Complete USB transactions. 



a USB network to 127 attached 
devices. After the address field comes 
the endpoint field. Endpoints are sub- 
addresses within a particular function 
of a device and are the actual data 
source and sink within that fimction. 
En<^ints will be discussed in more 
detail later. Note that in an SOF token 
packet, the 11 address and endpoint 
bits are replaced with an 11 -bit frame 
nimiber field. Finally, all token packets 
end with a 5-bit CRC. 

Figure 5 shows the format of a data 
packet. Data packets typically follow 
IN, OUT, and SETUP token packets. The 
originator of the data packet is the host 
for an OUT or SETUP token, or the device 
for an IN token. 

There are only two packet identifiers 
defmed for data packets, DATAO and 
DATAl. They are designed to sitpport 
toggle synchronization when transmit- 
ting multiple data packets. Data pack- 
ets must be an integral niunber of bytes 
long, to a maximum of 1,023 bytes. 
Note that the data packet has a 16-bit 
CRC. 

Handshake packets simply consist 



of an 8-bit PID, with no CRC. 
Permissible values for a Handshake 
packet include ACK, NAK, and STALL. A 
NAK indicates that an endpoint is cur- 
rently unable to accept data from the 
host or that it currently has no data to 
transmit. Note that a host can never 
issue a NAK; it must always be prepared 
to send and receive data. A STALL 
Handshake packet indicates that a 
fimction has serious problems and that 
' some host intervention is required to 
clear the stall condition. This is done 
by sending a SETUP transaction to clear 
the stall. Note that SETUP token transac- 
tions can never be ignored — they must 
be accepted and acted upon by a 
device. 

Currently, the only defined special 
packet has a packet ID of PRE. PRE 
packets signal a hub that a low-speed 
(1.5Mbps) transaction is about to take 
place and that any hubs with low speed 
devices attached should enable tiieir 
downstream ports. 

Figure 6 puts all these packet types 
together to show all the possible com- 
binations. In reality it is a fairly simple 
and straightforward implementation. 

TRANSACTION TYPES 

There are four types of USB 
transactions. Each endpoint is 
defined to support one, and only 
one, transaction type. Transactions 
may be either bulk, control, interrupt, 
or isochronous. 

Bulk transactions guarantee error 
fiiee deUvery of data between the host 
and a function endpoint. Bulk transac- 
tions start with the host issuing either an 
IN or GUT token as shown in Figure 6. If 
the host is writing data, it issues an OUT 
token followed by a DATAO packet. The 
function will then respond with an ACK, 
NAK, or STALL. The ACK signifies that the 
data was received correctly and the host 
may send the next packet, if any, in the 
data sequence. Note that the next pack- 
et in the sequence would be transmitted 
using a DATAl PID for the data transac- 
tion. If the data packet contains a CRC 
error, no handshake is transmitted by 
the fimction and a time-out occurs. 
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When a time-out occurs, the host will 

retransmit the data packet using the 
same PID as the failed packet. 

Bulk transactions do not have any 
guaranteed bandwidth associated with 
them. In fact, as will be shown later, 
bulk transactions use whatever band- 
width is left over after all other types of 
transactions have been serviced. 
However, when guaranteed, error-free 
delivery is required, such as in a scan- 
ner or a digital still camera, bulk trans- 
actions are the way to go. 

RGURE 7 

Control transfers. 



Control transfers are used for short 

command/control messages between a 
host and a function. There are typical- 
ly two stages in control transfers, setup 
and status. There may also be a data 
stage in between the setup and status 
stages. As mentioned previously, func- 
tions cannot ignore setup tokens; 
therefore, a NAK or STALL status 
response is not permissible. If the 
SETUP token packet is corrupted, it 
should be ignored and a time-out will 
occur. 



When guaranteed, 
error-free delivery 
is required, builc 
transactions are 
tlie way to go. 

All control transfers start with a 
setup stage. If there is a data stage to 
follow, it will adhere to the same rules 
as a bulk transfer stage. Finally, the 
status stage completes the handshaking 
sequence. Figure 7 illustrates the three 
possible types of control transfers. 

Interrupt transactions are a bit of a 
misnomer. No device othra* than a host 
can initiate a USB transaction. What a 
device can do, however, is have the host 
make a regularly scheduled polls of the 
device. The frequency of polling is spec- 
ified by the device during the bus enu- 
meration process, which is described 
later. The polling process simply con- 
sists of the host sending out an IN token 
packet to the device and the device 
responding with either a data packet (if 
new data is available) or a NAK or STALL 
(if data is not available). Note that the 
maximum allowable data payload for an 
interrupt fransaction is 64 bytes. 

One of the key elements of USB for 
telephony and audio applications is the 
ability to provide a guaranteed amount 
of bandwidth for a particular peripher- 
al. USB uses isochronous transactions 
to provide a constant bandwidth, error 
tolerant data fransfer mechanism. A 
device that requires a certain through- 
put rate will request it during the dis- 
covery and enumeration process. 
During each USB data frame, which 
occur at 1ms intervals, the host will 
either read from or write to the isochro- 
nous device, depending on the direc- 
tion specified by the device at enumer- 
ation time. This process is similar to 
the interrupt transactions but with a 
few significant differences. First, the 
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FIGURE 8 

USB frame structure. 
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FIGURE 9 

USB communication layers. 
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FIGURE 10 

USB device software entities. 




isochronous transfers occur every 
frame, while the interrupt transfers 
may or may not, depending on the 
requested interrupt frequency. Second, 
the isochronous transfers may be up to 
1,023 bytes long as opposed to the 64 



byte limit of an interrupt transfer. 
Finally, and most importantly, isochro- 
nous transfers are not acknowledged. 
For this reason, the data must be error 
tolerant. A CRC is present, so errors 
may be detected, but there is no capac- 



ity for re-transmitting erroneous data. 
If error-free transmission of large 
amounts of data is required, such as in 
the case of a scanner or digital still 
camera, bulk transactions should be 
used. If guaranteed bandwidth is of the 
utmost importance, such as in audio 
applications, then isochronous trans- 
fers are %e way to go. 

USB FRAMES 

The USB host controller breaks 
up data transfers into frames, 
which occur at 1ms intervals. 
During each frame, time is allotted for 
each transaction type with the follow- 
ing priority: 

■ Isochronous transfers 

■ Interrupt transfers 

■ Control transfers 

■ Bulk transfers 

Note that it is possible to have 
devices on the bus requesting more 
bandwidth than is available. In this 
case, the host would have to notify the 
user of this fact. The end user would 
need to remedy the situation, most 
likely by removing a device. Some 
devices could also have the capability 
to operate in a lower speed mode, such 
as a video camera operating at 10 video 
frames/sec instead of the normal 30 
video frames/sec. This situation might 
free up enough bandwidth to allow all 
the devices to remain on the network. 

All frames begin with a start-of- 
frame (SOF) packet, which includes 
the 1 1-bit frame number, and end with 
an end-of-frame (EOF) idle interval. 
After the SOF packet, the host services 
all isochronous devices on the net- 
work. Once isochronous transfers are 
complete, interrupt, control and bulk 
transfers are handled in succession. 
Figure 8 shows an example of a net- 
work with five isochronous fimctions: 
voice transmit and receive, modem 
data transmit and receive, and stereo 
audio. Note that the isochronous por- 
tion of each frame is always the same 
length, hence the guaranteed band- 
width. 
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USB DATA FLOW 

The preceding sections of this 
paper described the physical 
packet level side of USB. From 
the logical data flow perspective, there 
is much more to it than that. There are 
several layers of software in the USB 
model. 

On the host side, there is the host 
controller driver (HCD). This layer 



abstracts the actual USB controller 
hardware from the USB system. The 
upper layers need not know whether 
this layer is talking to a USB controller 
add-in card or to a USB controller built 
in to the computer's main chipset. The 
USB system software commimicates 
using the host controller interface 
(HCI). Currently there are two HCIs, 
the universal host controller interface 



(UHCI), which is provided by Intel and 
supports their chipsets, and the open 
host controller interface (OHCI), 
which was developed by Compaq, 
Microsoft, and National 
Semiconductor. While it may be a bit 
disconcerting to have two competing 
standards, developers of USB periph- 
erals and host applications will typical- 
ly not come in contact with the HCI 
layers; contact will be handled by the 
operating system transparently. 

Above the HCI sits the USB system 
software. This software manages the 
USB resources, such as allotting band- 
width, assigning addresses, scheduling 
interrupt transaction service, and so on. 
The system software conmiunicates to 
the host controller via the USB driver 
as do the client side applications. One 
note of caution to client side applica- 
tion developers: Microsoft's support of 
USB rests on the delivery of their new 
Win32 Driver Model (WDM) for 
Windows 95, the forthcoming OS97, 
and Windows NT. The WDM will look 
very similar to the current Windows 
NT drivers with differences in the dri- 
ver setup and shutdown procedures. 
Microsoft has been somewhat tardy in 
delivering the WDM, and its associat- 
ed generic class drivers, to OEM man- 
ufacturers, which has caused a signifi- 
cant delay in the proliferation of USB 
devices into the market. 

USB devices also have logical lay- 
ers of fxmctionality. Each of those lay- 
ers and some USB terminology will be 
discussed subsequently. 

LOGICAL LAYERS 

Endpoints are the sources and 
sinks of all USB communica- 
tion flow between the host and a 
peripheral. Endpoints have several 
characteristics associated with them, 
including the transfer type, bandwidth 
requirements (if isochronous service is 
specified), interrupt frequency (if inter- 
rupt service is specified), maximum 
packet size, and transfer direction of 
data (if bulk or isochronous service is 
specified). Note that each endpoint can 
only have one transfer type and one 
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direction associated with it. Full-speed 
USB devices may have up to 16 input 
endpoints and 16 output endpoints. 
Low-speed devices are limited to three 
total endpoints. 

All USB devices must have at least 
one endpoint and that endpoint will 
have an endpoint number of zero. 
Endpoint is used to initialize the 
device during the enumeration process 
and to provide configuration informa- 
tion about the device; therefore, end- 
point must always be defined as a 
control transfer endpoint. It may also 
be used after enumeration as a generic 
endpoint for control transfers. 

Pipes are the logical channels 
formed between a device endpoint and 
the host's data buffers. Pipes are creat- 
ed when a device is configured, and 
they assume the characteristics of the 
endpoint with which they are associat- 
ed. Two types of pipes are specified: 
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Device state machine. 
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USB Basics 



■ Stream: data that has no structure 
relating to the USB spec, such as an 
audio stream 

■ Message: data that has a defined 
USB structure, such as a configura- 
tion command 

Note that because all devices have 
an endpoint 0, all devices have at least 
one pipe, which is called the default 
pipe. As mentioned previously, the 
default pipe is used for all configura- 
tion functions and may be used subse- 
quently for other generic control trans- 
fers, although "ownership" of the 
default pipe is always held by the 
host's USB system software. 



Using the WDM model, the client- 
side software will typically request a 
data transfer via an I/O request packet 
(IRP) to a pipe. The client will then 
block on the IRP and wait, or be noti- 
fied via an interrupt. 

An interface is a collection of end- 
points that, taken together, provide 
the means to interact with a specific 
function. A function is defined as 
something that adds capability to a 
host, such as a printer or fax machine. 
From the client viewpoint, function 
interfaces are the entities bound to 
device drivers. Consequently, the 
pipes that are associated with the end- 
points comprising the function inter- 
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USB enumeration states. 
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FIGURE 13 

USB device request format. 
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GET.CONFIGURHnON data response. 



face are the means of controlling and 
transferring data between the client 
and the ftmction. 

Note that, during configuration, 
alternate interfaces may be selected 
for a specific fimction. An example of 
this might be a digital camera that can 
support the generic imaging class dri- 
vers that allow it to transfer images to 
the computer. During configuration, if 
only the generic driver is installed on 
the host machine, the configuration 
process would select the default fimc- 
tion interface. If the end user has a 
vendor supplied driver that supports 
looking at thumbnails of all the 
images stored in the camera or other 
enhancements, the configuration 
process could select the alternate 
function interface that supports these 
capabilities. 

Functions must have at least one 
endpoint. In fact, all fimctions must 
share ei^point 0. In addition, high 
speed devices may have an additional 
15 IN and 15 OUT endpoints. 

Devices are the highest layer of 
abstraction in the USB model. Logical 
devices can be either hubs or a collec- 
tion of one or more fimctions. Each 
device is accessed by a unique USB 
address that is assigned by the host 
during the enumeration process. The 
logical device is the container that 
holds all the interfaces and characteris- 
tics that enable the peripheral to partic- 
ipate successfully in USB's plug-and- 
play enviromnent. 

DEVICE FRAMEWORK 

The USB device framework con- 
sists of the items in flie follow- 
ing list: 

■ USB operational state machine 

■ Common set of g^eric USB opera- 
tions 

■ Common set of device requests gen- 
erated by the ^ost that must be 
responded to 
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■ Set of standard device descriptors 

■ Optional set of class- and/or ven- 
dor-specific descriptors 

THE USB STATE MACHINE 

A USB device has many possible 
states. However, not all of these 
states are visible to the firmware 
resident on the peripheral. Some of them 
are transient states controlled by the USB 
controller, be it an external chip, an off- 
flie-shelf microcontroller with an inte- 
grated USB port, or a custom ASIC with 
a USB core. The state machine is shovm 
in Figure 11. 

The states that are visible to the 
upper level software are as follows: 

■ Attached: the device is attached to a 
USB network, but the interface has 
not been powered 

■ Powered: the device is attached to a 
USB network and power is being 



applied to the interface via a hub. 
The interface has not yet been reset. 
USB devices may be powered by 
the bus or externally (self-) pow- 
ered. Note that even self-powered 
devices must report the maximum 
amount of power they will draw 
from the USB bus. Bus powered 
devices that draw more than one 
USB load (100mA) must be limited 
to drawing only one USB imit load 
imtil after the device has been con- 
figured. At that time a device can 
draw up to five unit loads, with the 
actual maximum level being report- 
ed in the configuration information 
of the device 

Default: the device is attached, 
powered and has been reset. It has 
not yet been assigned a unique 
address, only responds to the 
default address (0x00), and uses the 
default pipe 



Address assigned: the device is 
attached, powered, has been reset, 
and has been assigned a unique 7- 
bit address. No configuration has 
yet taken place. The device still 
only responds to requests on the 
default pipe, but now only at the 
assigned address 

Configured: the device has reached 
the address assigned state and has 
been configured by the host. The 
configuration process will be dis- 
cussed subsequently. Note that at 
this time, the device can be used by 
the host to provide its intended 
function 

Suspended: as a power saving mea- 
sure, USB devices must automati- 
cally enter the suspended state 
when the device has seen no bus 
traffic for a specified period of 
time. When a device is suspended, 
it retains any address and configu- 



r 



High performance memory emulation and 

debugging: 

' Stable and reliable on today's embedded systems. 
* New faster access speeds now standard. 
" The best connection solutions for TSOP, PSOP and PLCC chips. 
> Expanded Virtual UART support for industry-standard debuggers. 




Ultra-Fast code downloaik reduce 
development time: 

New high-speed download support for 
Windows NT 

90 KBytes/Second over a PC parallel port. 

low-cost Ethernet support for UNIX systems. 



New Lower Pric^ for 1 997: 

128 KByte PromlCE now 
just $495. 

Source-level debugging systems 
at a fraction of an ICE's cost. 



1 


- t 






5tter, fastei 




'.Call 1 


.8( 


Informatio 


n, or visit us at w 


WW. gel 


.CO 




i?r/has 
the tools 
you need for 

TORN^O 



Stethoscope® 
ControlSheir 
NDDS™ 

ScopeProfile 
RTILih 



TM 



Maximize your Tornado investment. 
Call, email, or visit RTI's web site: 
(408) 720-8312 • info@rti.com 
http ://wv»'w.rti.com 



• Application Visualization and Debugging 

• Visual Programming for Electromechanical Systems 

• Performance Measurement and Tuning 

• Real-Time Network Connectivity to Windows® & Unix 

• Memory Analy sis and Leak Detection 

Shaping the Future of Real-Time® 

Real-Time Innovations, Inc. 

155A Moffett Park Drive, Suite 111 
Sunnyvale, CA 94089 



@ 1997 Real-Ume Innovadoas, Inc. All ligbu reserved. SlelfwScope aiid Shaping the Future of Real-Time are registered tratiemarlts and NDDS and 

:|»Rei;e i m ON REAOIiit :|«@lViet 




ration data. The suspended state is 
tenninated as soon as some bus 
activity is detected 

A typical enumeration scenario is 
shown in Figure 12. When a device is 
attached to a hub, the hub signals the 
host of a change in status on one of 
the hub's ports. The host then queries 
the hub as to the nature of the change. 
When the host determines that a new 
device has been attached, it com- 
mands the hub to enable the port that 
the new device is connected to. At 
this point, the device changes from 
the attached to the powered state. 
This is the first time that the host can 
communicate directly with the 
device. From then on the sequence is 
fairly straightforward as the host 
resets the device, which puts it into 
the default state. Subsequently, the 



host uses the default pipe to assign an 
address and configure the device. 
Note that at any time after the device 
enters the powered state, if the device 
detects that the bus is idle for a spec- 
ified period of time, the device will 
place itself into the suspended state. 
The device will exit the suspended 
state and return to the previous state 
as soon as any bus traffic is detected. 

GENERIC DEVICE PROPERTIES AND 
OPERATIONS 

There are some specific proper- 
ties and operations that all USB 
devices must support. They 
include the following: 
■ Hot swapping: all devices must be 
physically able to withstand being 
connected to and disconnected fi-om 
the bus, with power applied, with- 
out damage ot causing damage to 



other devices. When a device is 
attached to a USB port, it must fol- 
low the state machine previously 

discussed 

Address assignment: all devices 
must be capable of changing their 
addresses to those assigned by the 
host 

Configuration: device must be con^ 
figured in order for the host to utilize 
the device's function. During con- 
figuration, the host requests specific 
descriptors from the device. These 
descriptors are structures that con- 
tain information regarding the capa- 
bilities of the device. The five types 
of descriptors are device, configura- 
tion, stting, interface, and endpoint. 
These descriptors will be described 
in detail in a later section. For now, 
let's say that the host can, by reading 
the descriptors, choose a specific 
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configuration for the device that 
suits the needs of the device drivers 
that are installed in the system 

■ Power budgeting: all USB devices 
may draw a maximum of 100mA 
from the bus be l ore ihey are config- 
ured. Once the configiu-ation is 
complete, they may draw up to 
500mA. The maximum current 
drawn from the bus is specified in 
the device descriptor. One note of 
caution here: just because a device 
can draw up to 500mA does not 
necessarily mean that a port can 
supply that much current. If that is 
the case, the end user should receive 
an error message from the OS stat- 
ing the error, and hopefully suggest- 
ing an alternative, such as trying a 
different port 

■ Remote wake-up: remote wake-up 
is not a required fiinction of a USB 
device. In fact, if it is included, 
there must also be the capability to 
disable the feature. With remote 
wake-up, a device is able to cause 
the host to resume from the sus- 
pended state. A good example of 
this is an idle computer that is con- 
nected to a USB compatible phone. 
If an incoming call is detected, the 
phone can signal the host computer 
to wake-up and handle the call. 

USB DEVICE REQUESTS 

All devices must respond to 
device requests from the host 
that occur on the default pipe. 
The default pipe uses control transfer 
type. Every request sent by the host has 
eight bytes in the following format: 

■ bmRequestType is a bitfield with the 
following characteristics: 

■ D7 - Data transfer direction - 
is host to device, 1 is device to host 

■ D[6:5] - Request type - = 
Standard, 1 = Class, 2 = Vendor, 3 
= Reserved 

■ D[4:0] - Request Recipient - 

= Device, 1 = Interface, 2 = 
Endpoint, 3 = Other, 4-31 = 
Reserved 

■ bRequest is a byte whose meaning 



can vary depending on the request 
type field in bmRequestType. For a 
standard request type, the values 
can be CLEAR.FEATURE, GET.CONFIGU- 
RAHON, GET.DESCRIPTOR, GET.INTER- 
FACE, GET.STATUS, SET.ADDRESS, 
SET.CONFIGURAnON , SET.DESCRIPTOR , 
SET.FEATURE, SET.INTERFACE, and 
SYNCH.FRAHE 

■ wValue is a 16-bit word whose 
meaning depends on the value of 
the bRequest byte. For example, if 
the bRequest is CLEAR.FEATURE, then 
the wValue describes the feature that 
should be cleared. In the case of a 
standard request type, the wValue 
could be either DEVICE.REHOTE.WAKEUP 
or ENDPOINT.STALL. If the bRequest is 
a__GET_DESCRIPTOR, the wValue would 
contain a descriptor type and 
descriptor index. Refer to table 9-2 
in the USB Rev 1.0 specification for 
more mformation 

■ windex is a word whose meaning 
changes depending on the request 
type. Again, refer to Table 9-2 in 
the USB specification 

■ wLength specifies the amount of data 
to be transferred in the data phase of 
the control transaction. The transfer 
direction is specified in 
bmRequestType, D7. If the field is zero, 
there is no data phase 

DESCRIPTORS 

Descriptors are data structures 
with a predefined format. All 
USB devices must report their 
characteristics and capabilities using 
descriptors. The five types of standard 
descriptors are device, configuration, 
string, interface and endpoint (as 
mentioned previously). There are also 
class and vendor specific descriptors. 
Both standard and class descriptors 
are essential to the plug-and-play 
process. 

STANDARD DESCRIPTORS 

Device descriptors contain gen- 
eral information about the 
USB device and specific 
information about the default pipe. 
The device descriptor is a variable 
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length structure that can be up to 256 
bytes long (although larger descrip- 
tors can be accessed using a proxy 
descriptor). Included in the device 
descriptor are the descriptor length 
and type (device), the USB revision to 
which the product was designed; the 
device class, subclass, and class-spe- 
cific protocol supported, if any; some 
vendor-specific information such as 
the vendor ID, product ID, an index to 
a string descriptor describing the seri- 
al number, an index to a string 
descriptor that describes the product, 
and so on; the number of configura- 
tions that the device supports (at least 
one); and the maximum packet size 
for endpoint 0. 

Even though one or more interfaces 
may use endpoint for control trans- 
fers, its packet size is only defined 
once and that definition is in the device 
descriptor. Note that because endpoint 
is standard among all devices, the 
only variable associated with it is the 
maximum packet size. 

Configuration descriptors contain 
information about specific device con- 
figurations. Remember, as mentioned 
previously, a device can have more 
than one configuration available, but 
only one can be active at a time. Other 
items the descriptor describes are the 
number of interfaces supported by this 
configuration, the configuration value 
(which is used by the SET.CONFIGURA- 
TION request), the maximum power 
drawn by the device when this config- 
uration is selected, and some configu- 
ration-specific attributes, such as 
whether the device is self-powered or 
remote-powered, and if it supports 
remote wake-up. 

Interface descriptors directly follow 
their associated configuration descrip- 
tor in the data returned by a GET.CONFIG- 
URATION request. Interface descriptors 
cannot be accessed independently of 
the configuration descriptors. Each 
interface descriptor is followed by its 
endpoint descriptors. If a configuration 
has more than one interface, the second 
interface descriptor follows the last 
endpoint descriptor of the previous 



interface as shown in Figure 14. Any 
additional interface descriptors are 
appended after the end of the last end- 
point descriptor of the interface that 
precedes it. (Note that interfaces com- 
mon to a configuration cannot share 
endpoints, with the exception of end- 
point 0. Also, if an interface uses end- 
point 0, it is defmed in the device 
descriptor and not redefined in the 
interface descriptor.) 

Interface descriptors contain infor- 
mation about the interface number, the 
number of endpoints contained in the 
interface, and any class, subclass and 
class protocol that might be associated 
with this interface. 

Endpoint descriptors contain the 
information used by the host to set up 
the scheduling and bandwidth alloca- 
tion desired by the device. The end- 
point descriptors contain an endpoint 
address, which consists of a 4-bit 
address and one bit for direction; the 
endpoint attributes, (whether it is a 
control, isochronous, bulk, or interrupt 
endpoint); the maximum packet size 
the endpoint is capable of sending or 
receiving; and a polling interval that 
sets the interval (in milliseconds) at 
whi^ an interrupt endpoint will be 
queried. Note that the polling interval 
must be set to one for isochronous end- 
points and it is ignored for balk and 
control endpoints. 

String descriptors are unicode- 
encoded strings that contain human 
readable information about the device. 
String descriptors are optional, but if 
they are not supported, all references to 
them must be set to zero. 

CUSS DESCRIPTORS 

Designing a product to belong to 
a specific USB class is entirely 
optional. If the product vendor 
wants to supply a proprietary driver 
without which the device will not oper- 
ate, they may do so. If this is the case, 
it must be indicated by having the 
DeviceQass member of the device 
descriptor set to OxFF. However, to 
truly participate in the plug-and-play 
configuration scenario, a product 
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should belong to a specific device or 
interface class. With Microsoft's new 
Win32 Driver Model, for each USB 
device class there will be a generic 
class "minidriver" supplied with the 
OS that will support the basic ftmc- 
tions of that class. If the manufacturers 
wish, they may supply their own dri- 
vers, which may make use of some 
added device features, but the devices 
should still operate without them. 

The currently identified device 
classes are as follows: 

■ Audio 

■ Communication 

■ Hub 

■ i I iiiiian Interface 

■ Image 

■ Monitor 

■ PC Legacy 

■ Physical 

■ Power 

■ Printer 

■ Storage 

At this time, not aU of these class 
specifications have reached the release 
stage. The most current information 
can be found on the USB home page 
(www.usb.org). 

Many classes are defined at the 
interface level, not the device level. 
This situation allows for multifunc- 
tional devices to contain more than one 
class-specific interface without the 
need for implementing a hub. A good 
example might be a fax/scaimer/printer 
device. The fax interface might belong 
to the communication class while the 
scanner would have an imaging class 
interface, and the printer fimctional 
interface would follow the printer class 
specification. Another issue with such 
a device is that the new multiftmction 
peripheral interface (MFPI) communi- 
cations protocol accoimts for the multi- 
ple functions of the device. The 
designer must decide what class defin- 
itions to support. One solution to this 
particular question would be to support 
multiple configurations. One configu- 
ration could support the communica- 
tions, imaging, and prints classes, as 



mentioned above, while the alternate 
configuration would allow the device 
to use the MFPI protocol. The host 
could then decide, based on what dri- 
vers are available, which configuration 
to select. 

An example of a class specification 
is the imaging class. While, at the time 
of this writing, the imaging class is still 
very preliminary, it is a representative 
example of what a class specification 
contains. As mentioned previously, 
many classes are defined at the inter- 
face level, not at the device level, and 
the imaging class is no exception. 
When using an interface level class, 
the device descriptor's DeviceQass and 
DeviceSubCLass both must be set to 
zero. Members of the imaging class 
would declare themselves as such in 
the blnterfaceOass. The 

blnterfaceSubCLass entry further delin- 
eates the imaging class into SCANNER, 
STILL.CAHERA, and VIOEO.CAHER* sub- 
classes. The specification goes on to 
define some specific endpoints that 
would be required by each subclass, 
such as a bulk IN for digital still cam- 
eras and scanners, and an Isochronous 
IN for video cameras. 

When the host is preparing to con- 
figure an imaging class device, it 
would send a GET.DESCRIPTOR request 
with the recipient set to INTERFACE and 
the type (wValue) set to CLASS. The 
imaging peripheral would respond 
with a class descriptor followed by one 
or more control descriptors. Similar to 
the case of interface and endpoint 
descriptors, control descriptors would 
only be accessible by reading the class 
descriptor. Control descriptors would 
be used for setting such parameters as 
scanner resolution, exposure times, 
and so on. Controls could be imple- 
mented as : 

■ Continuous types: image size, scal- 
ing, cropping, exposure, and so on 

■ Bitset controls: start, stop, next 
index , previous index, and so on 

■ Table-driven types: such as a choice 
between 200, 300, 400 and 600 DPI 
on a scanner 



■ Still-image modes: such as the num- 
ber of bits per pixel or the image 
format (JPEG, FlashPix, or T.6 Fax 
encoding, and so on) 

■ Video image modes: Raw RGB, 
CCIR-NTSC, CIF/QCIF, Indeo, 
and so on 

These predefined control descriptors 
could then be used by either the gener- 
ic imaging class driver or in an 
enhanced features mode by a driver 
supplied by the vendor. Since the 
imaging class is still preliminary, 
caveat emptor. 

NEXT TIME 

In this article, we've looked at some 
of the details of the USB specifica- 
tion. For more detailed informa- 
tion, refer to the references listed 
below. Next time we'll look at some 
the USB peripheral controllers that are 
available and investigate some of the 
issues that need to be addressed when 
implementing a USB peripheral 
device. HMiJ 

John Canosa is a principal member of 
the technical staff at Questra 
Consulting, where he is responsible 
for designing and developing hard- 
ware and software for embedded 
designs. 
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Want to know how to allow small microcon- 
trollers to be fast, use very little memory, 
and seem to do everything at once? Read on. 



If you're implementing a system 
based on a small microcon- 
troller that controls a large num- 
ber of I/O points and must 
exhibit fast response, here's an 
approach to programming that pro- 
duces fast, compact code for small 
microcontrollers, enabling them to 
quickly perform a wide variety of 
tasks. A small microcontroller might 
have 64 bytes of RAM, 2,048 bytes of 
ROM, and a l^s per instruction execu- 
tion rate. Although you'll find smaller 
computers than this, and some that are 
even faster, this is a good example of 
the challenge. 

The use of state machines for each 
function or task enables the software to 
be small yet respond quickly to real 
world events. Tasks include key 
debouncing, communications, LED 
flashing, and so on. Each function con- 
sists of a number of steps or states. 
Each individual state is a reaction or 
action that requires only a few instruc- 
tions to perform. The entire program 
consists of passing control to each 



function in turn. Each function only 

executes part of itself to act on or react 
to one step. The result is that the sys- 
tem seems to be doing everything at 
the same time. Consider Figure 1, 
illustrating the program looping 
through each function. Each function 
executes a small part of itself and pass- 
es control to the next function. 

This article introduces a variety of 
ways this concept can be implemented, 
accompanied with snippets of code. 
The code contains conmients to 
explain the instructions used. Please 
note that the code is neither totally 
accurate nor tested. It's purpose is to 
serve as illustration. 

To clarify this concept and expand 
upon its use, let's consider an example 
of a large tank filling with water and 
emptying repeatedly. Our little com- 
puter will control this process. 

The drawing in Figure 2 represents a 
large container with an input pipe in 
the upper left and an output pipe in the 
lower right. The input pipe is con- 
trolled by a valve as well as is the out- 



RGUREI 

Program loops through each function. 



1 



FUNCTION A 



FUNCTION B 



FUNCTION C 



The line with the arrow head represents the exe 
thread passing through the functions each loop.' 
Only part of each function is executed each time a 
function gets control. 

The blacic sections represent the part that is 
executed. 
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The use of state 
machines for each 
function or tasic 
enabies the 
software to he 
smail yet respond 
quicidy to real 
world events. 

put pipe. The valves are output devices 
in that the computer can open or close 
them. If the computer writes a to a 
valve, it is opened and allows water to 
flow. If the computer writes 1 to the 
valve, the valve is closed and no water 
flows. 

You can also see floats in the tank. 
Float A indicates the tank is full and 
Float B indicates the tank is empty. 
These floats are input devices that the 
computer is able to sense. If a float is 
up, it sends a value of 1 to the comput- 
er. If the float is down, it sends a value 
of to the computer. 

Our purpose in this task is to control 
the flow of water through the tank. We 



want to fill up the tank. Once full, we 
want to empty the tank completely. 
When it's empty, we want to fill it up 
again, and so on. The following C pro- 
gram describes how this task can be 
achieved: 

void NaiftCvoKl) 
{ 

NainLoop; //The program loops betueen here 

HachineOne( ); 
goto NainLoop; //and here, calling HachuieOne 
//each time 

} 

void NachineOneO 
{ 

//The switch statement passes control to one 
//of the states dependu^ on the veOue in 
//StateVariable 
switch(StateVariable) 
{ 

case FULDIG: //Here the StateVariable is equal 
//to FILLING 
if (EbatH = l)//if float a = 1 (up) * tJus code 
{ 

//The upper float moved up, start duofiing 

»al«e«=l; 

ValveBN); 

StateVariable=DUNPING; 

} 

break; 

case DUMPING: //Here the StateVariable is equal 
//to DUNPING 
if (ELoatB = 0)//lf fLoat B is (doun) 
//do this code 



FIGURE 2 

Tank of water as illustration of the repeated looping through of a program. 
Valve A = means ] 




Valve A = means 
valve is open 
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are comments, not code 



LISTING 1 

Water tank program in assembly language. 

£Nate >€@||iiiMHHIl^ 

MauLoop: 

Icall Machine ;execute HachineFunction 
sjmp MainLoop ;junip 1^ 




Machine: 

;These first few instructions transfer control to 
;one of the states of this machine, 
mov DPTR,#JmpTbl ;get address of the jump table 
mov a.StateVariable ;get value of StateVariable 
jmp 8a + DPTR Jump to JmpTbl + StateVariable 
JmTbl: 

ajmp FUlingState ;jump table 
ajmp DuDfiingState ;jump table 



FiUingState : 

;In this state float A is down and float B is up 

jnb FloatABit,DoNothing» ;FloatABit not set.jinp to DoNothingA 

; float A became 1, tank is full, change state to empty tank 

setb ValveABit ;ValveA=l; 

dr ValveBBit ;Val»eB=0; 

mov a, #2 ; change state to dumping 

mov StateVariable, a ;change state to dumping 
DoNothingA: 

ret 

DumpingState : 

;In this state float A is up and float 6 is down 

jb FloatBBit.DoNothingB ;tank not HT, do nothing 

iFloatBBit became 0, tank MT, change state to fill tank 

dr ValveABit ;l/alveA=0; 

setb ValveBBit sValveB=l; 

mov A,#0 ichange state to filling 

mov StateVariable, A ; change state to filling 
DoNothingB: 








{ 

/Ahe lower float moved down, start 

//fining. 

Valve»=0; 

ValveB=l; 

StateVariabte^FILLING; 

} 

break; 
} 

} 

Note these important features of lids 
implementation: 

■ There is a main control loop which 
constantly calls the "machines" 

■ Most of the time nothing is going 
on, so a "machine" is merely exe- 
cuting the same "state" over and 
over again. The if statement in 
each "state" is executed and finds 
nothing has happened. This requires 
but a few instructions 

■ When an event does occur, only a 
few instructions are executed to 
take some action and possibly 
switch to a new state 

The heart of the concept can be 
described like this: the main control 
loop calls routines to handle individual 
tasks in the system. Each routine con- 
siste of a state machine. Each state in the 
routine does one of two things. First, it 
checks to see if there is something to do. 
If not, control merely falls out of the 
ftinction. If there is something to do, the 
state does it and changes the state vari- 
able to execute another state on the next 
pass through the main control loop. The 
process of checking to see if there is 
something to do requires two or three 
instructions. The something-to-do can 
require less than 15 instructions or about 
15/u.s. Therefore, as many as 60 
machines could be executed within 1ms. 

IMPLEMENTING STATE MACHINES 

Let's continue our study of the 
state machine concept by using 
code suitable for microcon- 
trollers. The 805 1 family assembly lan- 
guage will be used. Our first task is to 
@}^ress the state machine in ass^bly 



language instead of C. The code might 
appear as shown in Listing 1 . 

You have two ways to pass control 
to the appropriate state in a machine. 
The method of using a vector table — 
the method in Listing 1 — ^is versatile 
and can be used with machines with 
many states. For machines with a small 
number of states, a few bits can be 
used to track what state the machine is 
in. For example, if a machine has four 
states, two bits can keep track of them. 
The example we have been usinf has 



two states, so only one bit is necessary. 

The example in Listing 2 is a rewrite of 
the above code using that one bit. 

STACK USE 

In a small microcontroller environ- 
ment, each byte of stack space 
must be carefully planned for. 
Following a few rules will reduce the 
system's demands on the stack. First, 
use the stack only for calls, and not for 
data storage. Second, keep the number 
of calls you use to a minimum. A call 
depth of one is not unusual. In this 
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lJSnNG2 

Using one bit as a state variable. 
HactuJieFunction: 

Jb StateVariatxLeBit.DuqpingState 
■QijigState: 

(P^ FIoatllBit,DoNothingA ;FIi>atlBit not setjiip to DoNothiJigA 

;float l became 1, tank is full, change state to erapty tank 

setb ValveHBit ;Valvell=l; 

dr VaLveBBit ;Val»eB=0; 

setb StateVariableBit ;change state to dumping 
DoNothingA: 

ret ; return to caller of HachineFunction 

DumpingState: 
;ln this state float A is up and float B is doun 
Jb FloatBBit.DoNotiiingB ;tank not HT, do nothuig 
;FlDatBBit became 0, tank HT, change state to fill tank 

^ ValveABit ;l/alveA=0; 
ValveBBit ;ValveB=l; 
dr StateVariableBit ;change state to filling 

OoNothingB: 

ret ; return to caUer of Nachind^unction 

.^HiliiliMllflaHlilll^^ 

UST1NG 3 

Flashing an LED. 

RBshLed: ;The nain loop calls this label 

jb LedStateBit,LedOff ;if LedStateBit = 1, jmp LedOn 
;if LedStateBit = continue here 



mm 



mov A,FlashTiiner 
jnz KeepLedOff 
mov TimerA,#10 
setb LedStateBit 

KeepLedOff: 
ret 

LedOn: 

mov A, Timer A 
Jnz KeepLedOn 
mov TiinerA,,tiO 
dr LedStateBit 

KeepLedOn: 



;get tijner to see if its zero 
;not zero, do nothing 
;is zero, restart timer 
;and change 

; return to caller 

;get timer to see if its zero 
;not zero, do nothing 
;is zero, restart timer 
;and change state 



41 



method of programming, subroutines 
are not often used. Special needs 
always exist, so a stack with a call 
depth of three is acceptable. With only 
64 bytes of RAM available, keeping 
the stack small is highly desirable. 

Normally the stack is also used for 
handling interrupts. That is, when an 
interrupt occurs, the interrupt routine 
saves all important registers, which can 
amount to more than 10 bytes. The 
space need not be reserved for inter- 
rupts if you use a technique that dis- 



ables interrupts during normal process- 
ing. Then interrupts are allowed during 
those times when nothing is happening 
and the registers are essentially not 
used. Consider this piece of code: 

NainControlLoop: 
Icall Hachinel 
setb EG ;allou interrupts 
clr EO ;enat>le Intarrupts 
Icall Machine2 
setb EO ;a]lou interrupts 
dr EO ; enable interrupts 



Icall Machines 
setb EO ;allou interrupts 
dr EO ;enabik interrupts 
sjifi NainCbntrcILodp 

Interrupts are handled between calls 

to machines. Because the registers are 
not being used, they don't need to be 
saved. This technique works because 
each machine only requires about 15/iS 
to get its job done. The interrupt laten- 
cy, llien, is ISfis, 'sMWeh is acceptable 
in most systems. 

BYTE TIMERS 

Timing events within your pro- 
gram is one of your more com- 
plex tasks. Often timers are 
required for a variety of uses, from 
communication time-outs to debounc- 
ing keys and flashing LEDs. The time 
control method presented here is sim- 
ple. In this method, a byte is used for 
each software timer we need. When a 
timer interrupt occurs, each byte is 
examined to see if it is 0. If it is not 0, 
it is decremrated: 

Timerlnterrupt: ;Execute this uhen interrupt occurs 

mov a,TuierA ;Get tuner byte into register a 

jz ItsZero iJump if Timer* is 

dec TinerA ;If it's not 0, subtract 1 from it 
ItsZero: 

iret 

If the timer interrupt occurs every 
1 00ms and a timer is set to, say, five, 
then the timer will time out or become 
zero between 400 and 500ms. 

When a task wishes to use a timer, it 
stores a value in the timer value. Then 
that task continues to test that value for 
zero. When it goes to zero, the task 
continues, knowing an appropriate 
time has passed. To demonstrate this, 
let's make a machine that flashes an 
LED (see Listing 3). 

MULTIPLE TIMERS IN ONE BYTE 

With the timer scheme just 
presented, each software 
timer requires one byte. If 
you have a number of items to time, 
you could expend a lot of precious 
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memory keeping track of them. Here's 
a scheme that enables four timers to 
exist in one byte. The layout of the 
byte is AABBCCDD. 

AA represents two bits for one 
timer, BB, two bits for the next, and so 
on. The idea is that each of these 2-bit 
timers is checked to see if it is zero. If 
not, the timer is decremented by one. If 
a timer is set to three or binary 1 1 , then 
the timer will time out or go to zero in 



three timer ticks. If the interrupt timer 
is ticking every 50ms, then this timer 
would time out in 100 to 150ms. 

Decrementing each 2-bit field in the 
byte would require about five instruc- 
tions for each timer. However, one 
bold method checks and decrements 
the four timers using four instructions. 
In this method, a timer byte is used as 
an mdex mto a table to retrieve a new 
tuner byte value. The values in the 
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table are such that the appropriate non- 
zero 2-bit fields are decremented while 
those that are zero remain zero. 

The major problem with this is that 
256 bytes of ROM are required. The 
real gain is that three bytes of RAM 
can contain 12 timers. With the byte 
method, 12 bytes would be required. 
Often you will have plenty of ROM but 
little RAM, so this scheme can be valu- 
able. The 2-bit timers are set with an OR 
instruction and tested using an AND 
instruction. 

USING A LARGE NUMBER OF TIMERS 

Decrementing all timers with 
each occurrence of an interrupt 
would be desirable, for the 
process could take longer than 15jU.s if 
there were a large number of them. 
Normally the timers need not be decre- 
mented on the same pass. In this 
scheme, the timers are not decrement- 
ed when the timer interrupt occurs. 
Instead, the timer interrupt sets 
TimersState equal to zero, then when 
the main control loop calls 
HandLeTimers the timers are managed. 

HandLeTiners: ;nHin control loop calls this label 

mov DPT1),#TijiierCode ;get address of TimerCode 
into OPTO 

mo* a, TimersState ;get offset into TiaerCode 
jap OaH)PI1{ ;Jiinp to the appropriate state 

TimerCode; 

mov TiinersState,(DI)EX.1D.TDGtt ;set if for next 
state 

;decreiiient timer here 

ret ;done uith this timer 

no» TifflersState,inOEX.1D.TDERB 
;decreMnt tiaer here 
ret 

ret ;this is idle state 

In this example, when the 
INDEX.TO.TUIER value is added to the 
TimerCode address, the jump indirect 
(jmp da+DPTR) instruction will pass con- 
trol to the appropriate routine. That 
routine handles the timer and selects 
the next INDEX.TO.nHER value. When 
all limefg are Mrailed, only #ie last 
state is executed, which simply returns 
until the timer interrupt resets the state 
variable to zero. 
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SWITCH DEBOUNCING 

Let's take a look at a real task and 
apply this technique to 
debouncing keys and switches. 
The debounce strategy is to accept a 
key closure immediately as a closure 
but wait for a while to allow bounce to 
occur before checking to see if the key 
has been opened. The same occxirs 
when the switch opens. We treat the 
initial opening as such, but allow some 
time to pass before checking to see if 
the key might be closed again. Those 
engineers who are worried about false 
signals due to noise on the wire from 
tile key can use an extra state to double 
check the key to make sure it's still 
closed a short time after the initial key 
closure, 

iDeboundjig a Key press 
; Key 1 is closed if KeylStateBit equals 1 
;Key 1 is open if KeylStateBit equals 
jKejfUnput is connected directly to key or 
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switch 

KEY1.T1I1ER.SET.HIISK equ OcOh 

;set mask for 2-bit timer 

KEYl.nMER.TEST.HJSK equ 3fh 

;test mask for 2-hit timer 

DoKeyl: ;Haiii control loop caUs DoKeyl 

ijump to appropriate state 

Jnb KeylStateBitl.KeylClosedStates 

jb KeylStateBit2,KeylOpenState 

sjmp KeylJustOpenedState 
KeylCLosedStates: 

jnb KeylStateBit2,KeylCliosedState 

sjinp KeylJustCLosedState 

KeylOpenState; 

;if Keyllnput =1, jmp to KeyJustOflsed 

Jb Keyllnput.KeyJustCLosed 

ret ;key not closed, do nothing 
KeyJustCLosed: 

orl KeyTiiiier,#KEVl.T3)IER.SET.H»SK 
;start debounce tuer 

set KeylStateBitl ; closed state 

dr KeyiStateBit2 ;Just closed state 

ret 



KeylJustCLosedState: 

mov a,#KEYl.ID1ER.TEST.HASK 
; check if tijner tijned out 

anl a.KeyTiiffir 

Jz QoseDebounced ;if it did do Jump 

ret ;if not, just return 

QoseDebounced: 

set KeylStateBit2 
;done debouncing, go to closed state 

ret 

KeylOosedState: 

;if Keyllnput =0, jmp to KeyJustOpened 

Jnb Keyllnput,KeyJustOpened 

ret ;key not closed, do nothing 
KeyJustOpened: 

orl KeyTijiier,#KEYl.TIHER.SET.H*SK 
; start debounce timer 

dr KeylStateBitl ;open state 

dr KeylStateBit2 ;Just opened state 

ret 

KeylJustOpenedState: 

mov a,#KEYl.TlHER.TEST.H»SK 
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; check if tuner tuned out 

anl 3,KeyTiiiier 

Jz OpenDebounced ;if it did do jump 

ret ;if not, just return 

OpenDebounced: 

set KeylStateBit2 
;done debouncing, go to open state 

ret 

In this routine, you can see the timer 
in use, which of course is decremented 
elsewhere in the program, and you can 
see that each step of the machine 
requires very few instructions to exe- 
cute during each pass through the main 
loop. 

DISPLAY DEVICES 

Our next example illustrates 
writing data to an array of 
LEDs (see Figure 3). Below is 
a simplified model made up for the 
purposes of this explanation. In this 
model, bits are fed into the DAT line 
one at a time. As the bits enter, they all 
move aroimd like a bucket brigade. 
The dots inside the dotted box repre- 
sent LEDs that make up a 5-by-7 char- 
acter array. If a one bit falls on a dot, 
that LED is lit. If a zero falls on a dot, 
it is not lit. The CE (chip enable), CLK 
(clock), and DAT (data) lines are 
manipulated to get the chips into the 
array. The CE line is brought high to 
start sending bits into the array. To 
move a bit into the array, the CLK line 
is raised to one. Then the DAT line is 
raised to one if a bit is to be moved in, 
otherwise the DAT line remains zero if 
a zero bit is to be moved in. Then the 
CLK line drops to zero to tell the array 
a bit is on the DAT line. That process 
is repeated for each bit. Then the CE 
line is dropped to zero, which tells the 
array all bits are in and the one bits can 
be turned on. 

The following code is designed to 
clock one bit in every pass through the 
main control loop. Note that to start the 
machine working the code invoking 
the. rouliBfe puts lie bits to make a char- 
acter into DataO-4 and sets LedState, 
the state variable, to LED.START.STATE. 
When the routine is done entering the 



bits, the state variable equals 
LED.IOLE_STATE. 

;NOTE: code to vector to liie state labels is not 

;dis|iLayed here 

LedMeState: 

;do nothj/ig until someone changes state vari- 
able to jLedStartState 

ret 

LedStartState: 

; Begin to display character in DataO-4 
mov rOjUDataO ;get index to first byte 
setb CE ; raise chip enable to urite bits to 

LED array 
mov LedState,#LED.Bn.ST»TE 

;syitch to display bit slate 
ret 

LedBitState: 
setb CLK 

; raise the dock letting LED knoti a bit is comity 

mov a,9r0 
{retrieve bits to write to LED array 

rlc a ; rotate a hit into carry flag 

mov DUTt.c 

; write the carry flag to the data out pin 
mov 9r0,a 

;save the bits to write to LED array 
dr CLK 

;drop clock informing LED the bit is done 
dr Dm 

;clear the data out pin to ready for next pass 

djnz BitCnt.StillBitsToDo 
;decrement hits to write 

;4 Jump if not done 

mov LedState,#LED.BYTE.ST»TE 
;done writing, change state 
StillBitsToDo: 

ret 

LedByteState: 

;here we check to see if there are more bytes to do 
inc rO 

jcompare index to end of data area, Jimp if not equd 
cjne rO,#DAT»4+l,StiILBytesToDo 
mov a,#LED_DONE.STATE ;we are done so 
mov LedState.a ;change state 
ret 

StDlBytesToDo: 

mftv Bittnt,#8 
;more to do so reset bit count, do it apin 

mov LedState,#LED.Bn.STIITE 
;done, change state to send bits 



ret 

LedDoneState: 
dr CE 

;drap chip enabQe causing character to be dis- 
(Hayed 

mov LedState,i.ED.IDLE 
;go to idle state because ve are done 

ret 

This routine would display a charac- 
ter in about 10ms. This assumes that 
for most functions the main control 
loop calls have nothing to do when 
they are called. 

COMMUNICATIONS 

Many microcontrollers support 
some sort of communication 
hardware. This could range 
from lie, SPI, SCI, or other serial 
communication systems. This hard- 
ware handles the details of communi- 
cation while the software acts in a 
supervisory role. The hardware pro- 
vides registers for the software through 
which control is effected. 

Here I describe a rough model of the 
commimications envirormient that con- 
tains common elements of these sys- 
tems. Then I'll present a sample of 
code that handles communication with 
the concepts presented in this article. 
Here's how the registers and hardware . 
flags may be organized: 

■ InByte: A register in memory which 
receives a byte from the outside 
world 

■ OutByte: A register in memory 
which sends a byte to the outside 
world 

■ RxFlag: A bit when set by the hard- 
ware indicates InByte has received a 
byte 

■ TxFlag: A bit when set by the hard- 
ware indicates OutByte has been sent 

To send a byte out of the system, the 
software would put a byte into OutByte 
and ths feardware, tecognizing ttie new 
data, begins to send the data serially 
out over the transmission line. When 
the byte is sent, the processor sets tiie 
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TxFlag, which may also cause an inter- 
rupt. When a byte comes in over the 
receive hne, it is moved into the InByte 
register. When a complete byte is 
received, the RxFlag is set which may 
also cause an interrupt. 

In this discussion we will assimie all 
necessary items have been condi- 
tioned. A communications clock has 
been set for the right rate and necessary 
control bits have been set to enable 
communication to proceed. 

For this example, assume we are 
using full duplex. Input always comes 
in over one wire and output signals go 
out over anotiier wire. Also assume 
that the messages are four b\4es long. 
This message must be received in less 
than 100ms. If that is so, the controller 
sends an ACK; otherwise, the controller 
will send a NAK. Also our example does 
not use interrupts but constantly exam- 
ines RxFlag and TxFlag, taking action 
when they are set. Only the input or 
read routine will be presented. 

The philosophy is the same as 
before; a function, named GetHessage, 
handles the job and is called fixim the 
main control loop. This flmction is a 
state machine. RxState is the state vari- 
able. The routine GetHessage accepts 4 
input bytes placing them into DataO, 
Datal, 0ata2, and Data3, which are loca- 
tions in RAM. 

GetMessage: 

.-NOTE: the code to vector to the state labels 
;has been left out for brevity 

RxIdleState: 

;this state is constanly executed while uaitii^ 

;for input 

;yhen it detects an iflput bjte it receii/es the 
;byte and prepares to receive the other bytes. 

jb RxFlag.Gotlnput 
;If RxFlag set Jump to Gotlnput 

ret ;Just return to caller, no input yet 
Gotlnput : 

mov a,Rx6yte 
;get input byte into rq;ister a 

mov rO.tDATAO 
; initial iTp index to message area 

nwv OrO,a 
;move register a into message area 

inc rO ; point at next MI slot 

mov a.KOm.TINQlUT ;fire iip tine out timer 



mov ConnTiiner.a 

mov a,#RECEIVE.STIITE 
jprepare to receive more bytes 

mov RxState,a 
;by changing to the receive state 

ret 

RxReceiveState: 

;Ms state receives input bytes 
;It checks the tijner to see if to much time has 
;passed. ttien all bytes have been read it 
;changes state to send an HCK mov a.COninTiiier 
; check to see if ue timed out 

jnz CheckForNext 
ljump if we have not timed out 

mov a,#RXTIHEOUT 
;fall to here with message timeout 

mov RxState.a ;and change to time out state 

ret 

CheckForNext: 

jb RxFlag.GotNext 
;if RxFlag set Jump to GotNext 
ret ;if not set just return la ciQler 

GotNext: 

;Here ue received another byte 

mov a.RxByte ;move byte to register a 

mov ®rO,a 
;move roister a into message area 

inc rO 

; point at next byte in mess^ area 

cjne rO,IOata3+l,Next 
;compare index to input data (rO) 
;and jump if not equal to Data3+1 address 

mov a,#R)l)ICK_STATE ;done receiving bytes, 

mov RxSt^te,a ; change state to send ACK 
Next: 

ret 
RxAckState: 

;Send ACK and change state to wait for ACK to be 
sent 

nov a,fn.REIJUBT.ACK.SEI«) 
;Setup Tx to send ACK 

mov TxState,a 

mov a,#RXACK.ilAn.STA1i 
; change read state to 

mov RxState, a ;yait for ACK sent 

ret 



RxAcktlaitState: 

;Vait for ACK to be sent then change state to 
;idLe state 

mov a,(tTxState 
;if Tx send state NE to idle 
cjne a,#TX.IDLE,AckNotSent ;ACK is not sent 
mov a,«RXJDLE 



;othendse fall here and charge state 

mov RxStiteja ;to idle State 
AckNotSent: 

ret 

RxNakState: 

;Send NAK and change state to wait for NAK to be 
;sent 

mov a,#TX.REQUEST.NAK.SENO 
; Setup Tx to send ACK 
mv TxState.a 
mov a,#RXNAK.«ACT.STATE 
mov RxState,a 
ret 

RxNakUaitState: 

;Vait for NAK to be sent, when sent change state 
;to idle 

mov a,#TxState 

cjne a,fTX.lDLE,NakNotSent 

HDV a,fRI.IDLE 

mov RxState, a 
NakNotSent 

ret 

SMALL FEATURE MICROCONTROLLERS 

In general the microcontrollers I've 
discussed here have been small but 
have still had several important hard- 
ware extras. Here's how to deal with the 
situation in which you have few or no 
luxuries at all. Consider, for example, a 
microcontroller without stack hardware, 
indirect addressing capability, or com- 
munication specific hardware. 

LIHLE OR NO STACK 

Some small microcontrollers have 
limited stack capability or none 
at all. The method 1 present in 
this article reduces the need for the 
stack. The main control loop used in all 
of the examples uses calls to all of the 
functions. The calls could be eliminat- 
ed by simply having all the functions in 
line. Instead of returning from the 
function when it completes, the pro- 
gram could Jump to the end of the 
function where the next function 
would begin. The stack is also used in 
many implementations as calls to com- 
mon routines. The approach taken in 
this article does not use common rou- 
tines since each state requires so few 
instructions. If a piece of code is used 
in more than one place it is simply 
duphcated. The reduced need for stack 
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space enables those microcontrollers 
with limited stack to use it for very 
important fimctions. 

NO INDIRECT ADDRESSINC 

The method presented here 
depends on the ability to use 
vector tables (via indirect 
addressing) to vector to the appropriate 
state. Here is an alternative. The state 
variable is decremented until it is zero. 
At that point the appropriate state is 
jumped to. Here is a code snippet 
showing this: 

AFunction: 

;iiain control loop calls this function 

imv a.StateVari^ 
;get state variable into register a 

jz StateO 
;if register a is jug)> to state 

dec a 

; subtract 1 from the register . 

Jz Statel 
;if reg a is nou Jump to state 1 

dec a ;and so on 

Jz State2 

The state getting control can then 



put a value into StateVariable to cause 
another state to be executed on next 
pass. 

COMMUNICATION WITHOUT 
COMMUNICATION HARDWARE 

Now consider a microcontroller 
that does not have the hardware 
to support communications. 
Assume we are building a "machine" 
that will monitor an input line and 
accept asynchronous 8-bit messages 
commonly fotind in RS-232 communi- 
cations. We don't need timer interrupts: 
the timer can be set up to run free. It 
can be constantly incremented so that 
when it reaches its maximimi value it 
will wrap to zero. We'll call the routine 
to handle all of this DoComm. It's called 
between each fimction call in the main 
control loop. The main control loop 
might appear as follows: 

HainControlLoop: 

call KeyBoard 

caill DoConm 
;Do input bit manipulation 

call Heater 

call DoComm 
;Do input hit manipulation 



call GetMessage 
call DoConn 
;Do input hit manipulation 
jnp RainControilLoop 

Notice the GetMessage function, 

which is similar to the communication 
function we discussed earlier. It's 
another task, just as it was before. 
Before, however, the hardware was 
getting the data for it to handle. Now 
the MMt ftmition handles this task. 
Timing is the critical aspect of this task 
and is handled as follows. Each state 
only executes about 15 instructions 
which should require about IS/as for 
each fimction. Then every 15/xs, or 
after each fimction, we call DoComm. 
Upon entry DoComm loops waiting for 
the exact time or "point of examina- 
tion" necessary for its processing. The 
precise time is in DesireTijne. The code 
might appear: 

DoComm: 

DesiredTime equ R4 

;this code snippit assumes an 8048 type 

architecture 

DoCommH: 

;Ioop to here to uait for right tine 
mov a,T 

;get time ticks from reg T into a 

;8048 has no compare, use xor,complement 

;for that 

xrl a.DesiredTiiiie 
;coinpare present tijne to desired tijne 

cpl a 

; compare present time to desired time 

jnz DoCommA 
;not yet, jump to DoCommA to try again 
;f:i]l here uith time to handle comiuikations 

add a.tCminilE ;set up to get next coiim 
handle time 

mov DesiredTime,a 
;save the next desired time 

;continue processus comnunications 

There are two critical times involved 
with the reading of an 8-bit byte. One 
time is the time to accept one bit. We 
can call that the hit time. The other 
time is how often we read the input line 
to check for that bit. That time is called 
the point of examination or Ucks in this 
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document. The time from point of 
examination to point of examination is 
one-tenth of the bit time. Another way 
to put it is the point of examination 
occurs 10 times more often than a bit. 
The code presented above in DoComm 
enables the "point of examination" to 
be precisely located. The structure of a 
byte coming into the read port may be 
as follows: 

■ A mark time which is at least 1 .5 bit 
times. Mark means the signal is 
high or one 

■ A start bit which is a zero-level sig- 
nal for 1-bit time 

■ Then eight bits follow, each bit 
being a bit time high or low 

■ After the eight data bits are 
received, the input line may enter 
the mark state for another 1.5 bit 
times or more 

DoComm must be written to accept this 



structure. As before, the DoComn func- 
tion is divided into states each one 
doing its small share of the whole oper- 
ation. The states could be as follows: 

■ Mark state: this state gets control 
constantly while the input line is 

one. When mark state detects a zero 
input, it assumes that it is the begin- 
ning of a start bit and sets up a 
counter to count ticks into the mid- 
dle of the first bit. Then the state is 
changed to read state 

■ Read state: when the tick counter 
goes to zero, read state reads the 
input line and rotates that value as a 
bit into a byte holding the input 
eight bits. The tick coimter is set up 
again to wait until the middle of 
another bit. This process continues 
until eight bits have been read. Then 
the state is changed to done state 

■ Done state: this state serves to noti- 
fy other parts of the program that a 



byte has been read. The other fimc- 

tion can read the state of this func- 
tion, find the state variable equal to 
done state and take action to move 
the new byte in. One of the actions 
would be to set the state variable 
here to find mark state 
■ Find mark state: this state continues 
reading the input line until it is one 
for 1.5 bit times. Then it changes 
the state to mark state. The process 
is ready to read another byte 

DIVIDE AND CONQUER 

The point I want to make in this 
article is that many tasks can be 
divided into smaller parts, each 
part of which is executed sequentially. 
This creates the illusion that all tasks 
are performed at the same time. This 
technique can be applied to almost any 
other task. Other fiinctions that can be 
adapted to this technique include mul- 
tiplying and dividing. These are loop- 
intensive tasks. Each loop could be a 
part of a math function that is execut- 
ed each pass of the main control loop. 
Managing serial EEPROM is another 
application. Each pass through the 
main control loop could set up or fin- 
ish a write. Often in manipulating 
these devices one must wait for some 
action to be completed within the part. 
With this technique, instead of wait- 
ing, the loop continues and other work 
is done. 

Perhaps some day you will try this 
idea on a project that has limited capa- 
bility and rewrite an old favorite rou- 
tine, finding, Hke the author, that the 
performance of these little chips can 
be impressive. B^U 

Al Schneider has a BS in physics. He 
has been programming for 26 years, 
concentrating on embedded systems. 
Presently he is a contract programmer 
and has worked on many applications, 
including pacemakers, airplane guid- 
ance systems, industrial HVAC inter- 
faces, and plastic and molten metal 
injection control systems. If you try 
using the technique described in this 
article, Al would like to hear from you. 
You can reach him at als@citilink.com. 
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What Have You JJebuggea 
For Me Lately? 



by NICHOLAS CRAVOTTA 



With increased inte- 
gration of tools, 
debuggers have 
come to possess, 
perhaps indirectly, 
more and more functionality. 
Debuggers can control compilers, link- 
ers, emulators, simulators, profilers, 
and a growing slew of other tools with- 
out bothering you for details. 
However, once you get past the issue 
of whether a particular debugger sup- 
ports your processor of interest, the 
marketplace is a battlefield of feature- 
spawning monsters, ominous tools that 
can do just about anything you want 
them to. Yet, while these monsters 
have plenty of exciting and even 
grotesque features, they tend to have 
appendages that aren't particularly 
useful. A flipper is great if you need a 
monster to swim, but a prehensile hand 
is typically much more useful. 

THE HEART OF THE MATTER 

If the debugger is the heart of your 
development system, the editor is 
the heart of your debugger. 
Brochures will tell you that a debugger 
is "easy to use," but imder what cir- 
cumstances is it easy to use? One way 
to understand "easy to use" is to focus 
on how you use your debugger most 
often. If it's difficult to control the fea- 
tures you use the most, you're liable to 
go crazy. Here are some considerations 
to keep in mind: 

■ Some editors automatically refor- 
mat your source code for you; some 
editors highlight keywords Mid olii- 
ers control tab spacing 

■ Editors can navigate code in many 
ways. For example, the editor may 
locate logical blocks, allowing you 



to click on an IF to find tiie corre- 
sponding ELSE and ENDIF 

■ If you've just spent half an hour 
opening all the right windows and 
placing them perfectly around the 
screen, you're definitely going to 
want the ability to record the setup 
for tomorrow's debugging session 

■ Assembly is sometimes displayed 
alongside C source code, some- 
times interspersed between lines of 
code. If assembly is in between, you 
may have difficulty seeing more 
than a handful of source lines at one 
time 

■ Having the ability to disable the dis- 
play of source code comments, 
especially the volumes produced by 
automatic code generators, can 
clear up a listing window 

■ Extensive on-line help can reduce 
the need for thick manuals on the 
desktop — especially if you can, for 
example, click on unfamiliar 
assembly instruction mnemonics 
and view a technical description 

■ The compiler knows all of the glob- 
al and lomi variables accessible 
from a particular function. This 
means the debugger should be able 
to bring up a window of all variable 
names within the current scope, 
saving you from having to remem- 
ber conet^ ^>eUings or where an 
instance of the variable appears in 
the source code in order to open a 
watch ^adow 

■ The size, type, and location of a 
variable can be as important as the 
value during debugging. Making 
the display of such information 
optional can keep watch windows 
compact 

■ "Out of scope" variables are often 
displayed as "not valid," taking up 



valuable screen space in the watch 

window. There are times, however, 
when you need to know the value of 
an "out of scope" variable, and you 
should not have to wait until the 
variable is back in scope to view its 
contents 

■ Being able to freeze the contents of 
a variable display window allows 
you to compare results to a later 
event without having to print the 
values to paper 

■ When debugging multiple tasks, the 
various windows associated with 
each task needed to be somehow 
grouped together, employing color- 
coding or some other scheme 

■ One-button system builds are a 
must, as well as are incremental 
compilation 

■ Downloading object files to your 
target should be simple. 
Incremental link-and-load support 
can reduce long downloads by 
downloading only changes 

This is just a short list of some com- 
mon features. You may want to con- 
firm how they are implemented before 
committing yourself to tearing your 
hair out every day because the debug- 
ger does things the wrong way — that 
is, not your way. 

DEBUGGER LOYALTY 

Depending on your project, you 
may begin development using 
a simulator, move to cross 
debugging (where the debugger is not 
on the target), and then employ an 
emulator. In some cases, you can use 
the same debugger in all three situa- 
tions. Additionally, if you work across 
multiple platforms with different real- 
time operating systems (RTOSs), 



JUNE 1997 EMBBIDBI SYSIBiS PROGRAMMOIG 79 



SPECIAL REPOR-P 



Software Debuggers 



Embedded PC 

Fits your applications 
and budgetl 

biscuit PC 

PCM-4824 

486 SBC With SVGA/LCD 




Fully PC Compatilfle. Easy to Install. 
Integrated Features include FDD, HDD. 
28/1P ports, Watchdog timer, PC/ia4 v 



expansion and more .. . ~X7"~ 

Biscuit PC, full size (s i/rFODsue) 

reM-5860 Pentium SBC wittlSVGA/LCD, 
It i: : : atwnwtand PCI Slot 
It PCM-486? «SBKwittiS\«A(iGD;e(iefnet 
andSDD 

Biscuit PC, lialf size (3 i/r hoo sUe) 

PCM-4824 486SBCvWW^i\itt(* ''-- 
PCM-4822 4868Bewih ihemKl';#^ 
PCM-4820 486 SBC ■'SHfifl! 
PCM-3864 386 SBC with SVGA/LCD V''-' 

Slot Single Board PC (isAj 

PCA-6151 PiMimWf-sizealHrt-oneew 

card with SVGA 
PCA-6145 486 hatf-size all-in-one CPU card 

with SVGA/LCD and Ethernet 

PC/104 Modules 

i : •Solid State Disks • PCMCIA • Ethernet •WVLCD 
JE 1 ««Hlti-poi1 RS-232 • RS-422/485 • Digital 1/0 
• A/D Converter ,ind mo^e. 

Call Today for a Free Catali^e ! 

A tridusiria/ Automation with PCs 

Ab\«^KrECH. 

U.S.A. 

750 East Arques Avenue Sunnyvale, CA 94086 

Tsl: (408)522-4696 Fax: (408)245-8268 SS ,,^, 

E-mail; infO'aAiJvantecli-USA.com 

litternatlonal 

ifMsNOi 108-3 Mina-Chuan Rtl . Sfiins-Tien, Taipei, Taiwan 
JESiiSS8&2-21 84567 Fax; 886-2-21 83875 
MUk/Aww jili/antech.com.tw 
E-mait iBt (acl.advantech.com.tw 
I .... j 



CIRCLE * 47 ON READER SERVICE CARD 



either on the same project or different 
ones, sometimes you can use the same 
debugger. 

Some debugger vendors achieve this 
portability by conceptually dividing 
the debugger into two parts: flie debug- 
ger environment, which is the same 
across the board, and a debugger inter- 
face, which is specific to a chip, 
RTOS, emulator, or monitor and 
across either serial, Ethernet, simulator 
data stream, or proprietary connection 
mechanisms. When you tell the debug- 
ger environment which of these you 
will be communicating with, the envi- 
ronment can dynamically customize 
itself, offering commands that apply to 
the particular context and tools. For 
example, a full emulator offers differ- 
ent functionality than background or 
JTAG emulation, and each RTOS 
offers different analysis support. 
Debuggers designed as open systems 
offer APIs capable of operating in a 
variety of applications and with many 
other tools. Some debugger interfaces 
ev^ offer limited skeleton code for 
getting on-chip peripherals up and run- 
ning so you can start code develop- 
ment before you've written any device 
drivers. 

An important characteristic of each 
type of debugging is whether it is 
intrusive or not. Intrusive debugging 
means that in some way the debugging 
tools can affect the execution of an 
application. Many analysis features 
require some kind of instrumentation 
in your code that requires time to exe- 
cute. For example, having a profiler 
instrument your code so that you can 
see what's happening can slow down 
execution. If you are running at peak 
performance, profiler overhead can 
cause side effects or failure that do not 
truly exist within your system. 

RTOS AWARENESS 

A debugger that interfaces with 
an RTOS may offer RTOS- 
aware features. Such a debug- 
ger will recognize RTOS system 
objects, such as queues, and be able to 
track intertask communications^ 



On the highest level, RTOS aware- 
ness supports dynamic analysis tools 
for monitoring tasks. Time graphs can 
display important interrupt informa- 
tion such as when an interrupt request 
arrives and when servicing of the inter- 
rupt actually takes place. This feature 
is usefiil for discovering if an interrupt 
process takes place within a certain 
time frame (and is the interrupt there- 
fore deterministic enough to process 
real-time data wilbout loss?) or if pri- 
ority inversion occurred (did a lower 
priority mterrupt hold up a higher pri- 
ority internq)t?). You can also deter- 
mine peak performance requirements 
for the system when it is under stress 
and measure how long a particular 
function took to execute. Displays can 
show CPU logs, system logs, tasks in 
order of priority, data streams between 
tasks, and dynamic statistical data such 
as how many times a particular task 
executes. RTOS participation in analy- 
sis is less intrusive than instrumenting 
code because the overhead for analysis 
occurs during RTOS fimctions such as 
context-switching, not in the middle of 
a fianction in which interrupts might be 
disabled. 

On a code level, an RTOS-aware 
debugger can ease the pain of debug- 
ging multitasking systems. A control 
window shows all threads njnning on a 
processor. You can suspend, spawn, or 
resimie thread activities. Clicking on a 
thread brings up a debug window for 
that thread. Debugging message pass- 
ing between tasks is easier because 
you can suspend the receiving task and 
trace the origination of the first task's 
message. 

Setting breakpoints in a multitask- 
ing environment brings up the issue of 
whether a breakpoint is global or local 
to a single or defined group of tasks. 
For example, setting a breakpoint in a 
system-level function should only 
break in the tasks you want it to. There 
are two ways to implement this kind of 
breakpoint: the breakpoint is always 
set, and when it triggers, the debugger 
determines if this is a task for which it 
is enabled; or liie RTOS sets the break- 
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OTHER ASPECTS OF DEBUGGING 

debuggers cover the implementation phase of design and some 
jugging. Yet debugging covers only o port of the territory you 
alore as you monitor a design to determine where and how it fails 
aectations. Today, tools can help you verify your application on 
cation and system levels, build a proof-of-concept, simulate and 
user interface, automate test suites, and manage software to 
Ran error: 

Specification and system level tools allow you to use state machines 
or block diagrams to build a running model of your system and prove out a 
design. At this stage, you can verify interaction between system components, 
explore the effects of boundary and error conditions, and possibly create a 
virtual prototype of your design 

Virtual prototypes allow testing of user interfaces for usability and a 
determination of just how idiot-proof a system really is. Some virtual proh 
types are executable files you can ship to the people who will eventually; 
sign off on your design, giving them a chance to determine if you have 
their expectations (not necessarily specifications) for the application early in 
the design cycle 

Simulators offer the opportunity to write and test code before hardware 
even exists. Simulators also provide an intimate window into a processor, 
allowing examination of cache performance and pipeline efficiency 
Profilers verify code coverage (whether or not every line of code executed 
during testing) and characterize where the majority of execution time is 
spent, thus locating bottlenecks and potential functions to hand-optimize 
Test suites automate the testing of a system. Test suites can test systems 
overnight, verifying that the latest set of changes has not introduced any old 
bugs bock into the system by running test coses that expose all known bugs 
Software management tools, such as version control software, help 
manage code among teams of developers. These tools con prevent develop- 
^ers from unwittingly wiping out each other's changes. Some software mon- 
logement tools track all changes made to the system by developer, descrip- 
tions of the fixes, and reasons for the fixes, thus allowing other developers to 
know who wrote a particular section of code and why the program has that 
statement that looks like it does absolutely nothing useful at all 

Traditionally, you might have mocked up a few of these tools yourself. For 
example, an algorithm could be proven using a BASIC program. The prob- 
lem with designing your own tools is the time spent not designing your appli- 
cation; you'll spend valuable, the-project-is-lote debugging time debugging 
your debugging tools. Many of today's debuggers, if they do not add func- 
tionality directly to the debugging environment, integrate directly with other 
tools, providing seamless access to test suites and profiling tools, for exam- 
ple. Remember, good design tools allow you to monitor your application arid 
determine where it foils to meet your expectations. Many bugs arise from the 
development process itself through human error, and the right tools con save 
you hpprst.of single-stepping by allowing these bugs to be identified in earlier 



point every time there is a context 
switch to a task for which it is enabled 
and resets it when leaving the task. The 
first method can hiccup a system 



because breakpoints will trigger daring 

tasks in which they may not be desir- 
able. The second method adds minor 
overhead to the context switching 



process, depending on how many 
breakpoints you have activated. 

Multiprocessor debuggmg is similar 
to multitasking debugging except that 
each processor needs to have an RTOS 
or monitor through which the debugger 
can communicate. This boils down to 
an interface issue as to which proces- 
sor is the control processor that the 
debugger hooks into, and which 
processors communicate debug infor- 
mation through that control processor. 

Finally, on the lowest level, an 
RTOS-aware debugger can help inte- 
grate an application on top of an 
RTOS, giving you the perspective of 
the RTOS as part of the application. 
This can be useful while developing 
device drivers or chasing problems that 
trash the RTOS itself (or the debug 
monitor). If you have a proprietary 
RTOS and the debugger has an open 
API, you may be able to map your pro- 
prietary API to the debugger API and 
observe your RTOS ia motion. 

ADVANCED SUPPORT 

Some less used advanced features 
of interest include profiling, ver- 
sion control support, and memo- 
ry eiTor detection. (See "Other Aspects 
of Debugging" for a description of 
these and other advanced debugging 
tools.) Here are a number of ways to 
instrument code for profiling: 

■ Single-step through code 

■ Use an auxiliary timer and interrupt 
to record the instruction pointer x 
times per second 

■ Record an instruction by instruction 
log from a simulator 

■ Collect trace data from an emulator 

By running profiles when the appli- 
cation is in different configurations, 
you can build a typical picture of 
which part of your code runs most 
often. Note that the first two methods 
are intrusive. The third method is not 
Intrusive but it ie aleo not Teal-tiine. 
The fourth method is both non-intru- 
sive and real-time. 

The second method above, using an 
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auxiliary timer, actually makes a statis- 
tical reckoning of which code con- 
simies the most execution time. Even 
with a couple of thousand samples, you 
can get a realistic idea of where your 
bottlenecks are. Despite the fact that 
your application may have a million 
lines of code, only a small subset of 
this code will execute regularly, and 
chances are a random sample wiU fre- 
quently fall within it. 

Some debuggers have integrated 
with version control tools. When you 
open a window to debug code, the 
debugger checks out a read-only copy 
of the source. When you begin to make 
changes, the debugger will attempt to 
raise your rights to write access. The 
advantage of version control software 
is that if a section of undocumented 
code makes no sense or appears to be 
in error, you can call up its history to 
trace the changes the code has gone 
through and who made them. You may 
be able to get a comparison listing of 
the code against the last set of changes. 
In any case, you can get a better idea of 
what the code is supposed to do or 
what bug it fixes instead of simply hav- 
ing to guess or curse out the idiot 
responsible for the code (who might 
even turn out to be yourself!). 

The main problem with version con- 
trol software, however, is that you 
don't want to make experimental 
changes to code that others may count 
on as reliable. In this case, you'll need 
to create a experimental directory 
branch, separate from the original 
source files but initially a perfect 
duplicate, for building and debugging 
your application. Create another dupli- 
cate of the master directory so that 
when your experiments are over, you 
have an original copy to compare 
against — the master directory may 
have been changed by someone else by 
then. 

Memory error detection software 
can help you quickly find common 
types of errors associated with allocat- 
ing and using memory. These tools are 
highly intrusive, instrumenting your 
code to detect use of uninitialized 
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Fax: +972 2 5864008 
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Multitasking in Real and 
Protected Mode 



MODULAR 
MULTITASKING 



Networking 




smxr Full-featured, high-perform- 
ance, preemptive kernel. Custom- 
ized to x86 & PowerPC processors. 
Ideal for demanding applications. 
Real mode worl<s stand-alone or 
with DOS. 16-bit, segmented 
protected mode works with 
pmEasyld. 32-bit, flat protected 
mode works with pmEasy32. 



mtxNet TCP/IP staci<. Fast UDP. 
Packet driver interface. Ethernet, 
SLIP, and PPP drivers. RP, SNMP, 
NFS, DHCP, IVIicroWeb, & othets. 



Task-Level Debugging 



smxProbe'!'' Provides tracing and 
symbolic debugging. smxAware'" 
works with code debuggers. 
Local or remote operation. 



C++ Classes 



Protected Mode Environment 

fpmEasy^ 1 6- or 32-blt protected 
mode entry, DPMI services, appli- 
cation loaders, Soft-ScopePond 
SoftProbeP debugger support. 

DOS-Compatible File System Dynamically Loadable Modules 



smx++" Class library built upon 
smx. Provides fully OOP-compat- 
ible support and services. 



smxFile'!' Full-featured file 
manager. IDE, floppy, flash, 
RAIVIdlsk, and PCMCIA drivers 
available. 



smxDLM. Runs independent 
executables as tasks which may 
be downloaded or loaded from 
disk, floppy, flash, etc. 



User Interface 



DOS & Windows Emulation 



o 



smxWlndows. Text windowing. 
Dresses up user Interfaces. Zinc® & 
MetaWINDOW" GUI support. 



unDOS" DOS, BIOS, and Windows 
partial emulator. Adds real mem- 
ory. Eases port to protected mode. 



NO ROYALTIES • 6 MO FREE SUPPORT • 30-DAY FREE TRIAL 



MICRO DIGITAL INC 1-800-366-2491 fax 714-891-2363 
http://www.smxlnfo.com sales@smxinfo.com intn'l 714-373-6862 
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Software Debuggers 



pointers, memory leaks, and other 
common memory misuses. When an 
error is detected, the program breaks 
and notifies the debugger of the error, 
,offering information such as the origin 
of a particular allocation and where the 
error actually took place. Make sure 
that you have access to a list of calling 
functions that goes back a number of 
levels. Often these errors will be 
caught in malloc, and if you have a 
wrapper around malloc, you need to 
know who called the wrapper to deter- 
mine the leak's location. 

COMMAND LINES 

Almost everyone is pushing 
graphical user interfaces (GUI) 
these days. GUIs are more 
intuitive, easier to use, and better for 
you than command lines interfaces. 
I've never been convinced of the 
absolute truth value of this last state- 



ment, having grown up on command 
line interfaces. I would prefer to see a 
hybrid approach offering both inter- 
faces, for each has powerful advan- 
tages. For example, with a command 
line, your debugger can record a series 
of commands and repeat them or allow 
you to alter a single value and run the 
whole sequence again. This is not as 
easily accomplished when commands 
are mouse clicks, although macro tools 
are improving. More importantly, 
however, you can display a list of pre- 
viously entered commands and under- 
stand what you just did wrong. 
Displaying the last fifty mouse clicks 
(oh, were you recording them?) yields 
a sequence of text commands concep- 
tually different from the mouse clicks 
associated with them. 

Having an active command line is 
critical. You could zero out all the val- 
ues ift ah array one at a time using a 



dialogue box, or you could write a 
quick loop on a command line to do it 
for you. While stopped at a breakpoint, 
you can copy lines of source code to 
the command line amd execute them 
out of order, even calling fiinctions or 
library routines. You can display data 
or analyze it without altering the data 
or leaving the environment. Traditional 
debugging envirormients require you 
to capture data to a file, then run your 
home grown display program outside 
of the environment to view the results. 

Many debuggers are begiiming to 
featxire application-specific and true 
object-oriented debugging. For exam- 
ple, 1,000 points of waveform data 
make much more sense when dis- 
played as a waveform and not as 1,000 
contiguous words of memory. You can 
create your own displays with buttons 
and parameters to display data in its 
most useful formats. For objects. 



DSP DEVELOPMENT TOOLS 
FOR TMS320 FAMILY 



XDS510PP EMULATORS 

• TMS320C3X, C5x, C54x, C2xx 

• Scan Path Emulators with Tl HLL Debugger, 

and GO DSP Code Composer 

• Portable & laptop operation via printer port 

EVALUATION MODULES 

• TMS320C50, C51 , C52, C20x, C24x, C54x 

• Standalone operation, RS232 PC based 

• HLL Debugger Available 

SOFTWARE 

• Debuggers, and Visual Basic Interface 

• Compilers, Assemblers, Linkers 

• Real-Time Kernels (RTOS) 

CUSTOM DESIGNS 

• * data sheets on website 



^DSP 

Texas Instruments 
DSP Solutions 



SF>ECri<Um DIGI"ML 

inCQRPOR/ITLD 

T: 281/561-6952 F: 281/561-6037 
sa(es@spectruindlgltal.coni 
www.spectrumdigital.com 
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Industrial Quality PCMCIA Card Drives 

Adtron's PC Card Drives connect to the 
ISA • RS232 • LPT • ATA • IDE • SCSI • PC/104 
ports of a PC, workstation or embedded computer 
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debuggers should allow you to have 
specific debug object extensions, not 
necessarily intended for download to a 
target, for displaying and analyzing 
data in a manner natural to the object. 
To display a linked list, for example, 
you should not have to follow the NEXT 
or PREV pointer 10 times to see the tenth 
item in the list. A window displaying 
the five previous items and the next 
five items could save you from having 
to open 10 variables and arrange them 
on the screen. 

DEBUGeiNG THE DEVELOPMENT 

PROCESS 

Application development meth- 
ods have changed and continue 
to change. With memory 
prices dropping, writing compact code 
isn't as important as getting the design 
to market. Faster processors transfig- 
ure sloppy code that was slow a year 



ago into functional and efficient code 
today. Upgrading a processor or clock, 
while throwing money at the slow soft- 
ware problem, may save you money in 
the long run by reducing development 
times and avoiding challenging code 
optimization. In general, embedded 
development doesn't involve byte or 
cycle coxmting the way it used to. 

Additionally, as processors become 
more complex, traditional methods fail 
to do the job. For example, it can be 
difficult to understand exactly what a 
processor is doing as caches grow and 
pipelines become longer and wider. 
Visualization of objects becomes more 
complex as the objects themselves 
become more complex. Applications 
such as signal processing call for stan- 
dard display options of data, including 
graphical plots and autoscaling. 

And so we come full circle. As appli- 
cations become more complex, design 



tools need to simplify that complexity. 
In one sense, the fact that your debug- 
ger has a super feature that you mi^t 
possibly use once is relatively unimpor- 
tant. If it's a worthwhile feature, the 
other debuggers will pick it up within 
six months to a year. What matters is 
what your debugger does for you today 
and every day, and that it does it the 
way you find most useful. Just as a 
small portion of your code constitutes 
the majority of execution time, you'll 
find yourself using mostly a small sub- 
set of the debugger's feature set — a 
subset that, hopefully, doesn't make 
you hate your debugger or spend all of 
your time trying to get it to cooperate. 
For a comprehensive listing of software 
debuggers, check out www.embed- 
ded.coiii/97/sr9706.htm. 



Technical editor Nicholas Cravotta 
can be reached at ncrayottaCdmfi.com. 
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PC COMPATIBLE! 



Just connect a keyboard, 
monitor/LCD, a disk drive 
and your ready to run. Or i 
forget the drive and boot 
directly from a Flash disk. 
Add PC/ 104 Modules for 
Fax/Modem, SCSI, Ethernet, 
Dlgltal/Analogl/O, and PCMCIA. 
Great for Point Of Sale and Web 
Browsers/Servers. Prices start at $200.00 Qty. 1. 

• Wide CPU Selection: 386SX, 486DX, DX2, DX4, 586, Pentium. 

• All SBCs have Real Time Clock, Serial, Parallel, IDE, and Floppy. 

• On Board Watchdog Timer. 

• BIOS with Power Saving Green Mode. 

• Wide Bus Selection: PC/ 104, ISA, PCI. 

• 10.4" TFT super bright LCD Panel Kits. 

• Hardware and Cable Icits Included for most boards. 
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RTKernel 

Professional, high-performance real 
time multitasking system for DOS 
and 1 6-bit Embedded Systems. 

For Borland aC++. Microsoft aC++,and Borland Pascal. 
Libraries: $550 Source Code: add $500 
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RTTarget 

Cross Development System 
for 32-bit Embedded Systems, 

Supports Intel 386 and higher, as little as 16k RAM/ROH. 
For Borland C/C•l--^, Microsoft C/C-^■^,and Watcom a(.++. 
Libraries: $1700 Source Code: add $1000 

RTKernel-32 

Professiorial, high-performance real- 
time multitasking system for 32-bit 
Embedded Systems. 

Supports Intel 386 and higher. 

For Borland C/C++, Microsoft aC++,and Watcom C/C++. 
Libraries: $1950 Source Code: add $1650 
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Fundamentals of FIR Design 



Sometimes the math involved in 
signal processing obscures the 
underlying simplicities. Math, 
like it or not, is the most descriptive 
language available in these matters. 
Unfortunately, despite the discipline 
inherent in mathematics, it is not a 
standardized subject — each author 
uses his or her favorite notations for 
whatever is being discussed. It isn't 
uncommon to be unable to find the def- 
inition of a particular symbol in a par- 
ticular discussion or derivation. 

This column marks the begirming of 
a short study of the elements of digital 
filter design, beginning with FIR fil- 
ters. In addition to the mathematics, I 
vAll also introduce some code as an 
example of applying the techniques 
involved. The principles involved are 
based upon certain dualities in signal 
processing that can make the subject 
more tractable for those who aren't as 
Well-versed in the subject. 

TIME DOMAIN/FREQUENCY DOMAIN 

The FIR filter, a filter without poles, is 

an invention of digital signal process- 
ing — it doesn't even exist in analog 
si^al processing. The filter is actually 
a polynomial approximation following 
directly from the Weierstrass theorem, 
which states that for any function ^Jc) 
continuous on [a,b], there exists a 
sequence of ordinary polynomials 
which converges uniformly to^^) on 
[a,b]. Loosely, this means that given a 
sufficient number of terms, we can 
usually approximate any function that 
ejtists in nature with a polynomial. 

FIR filters can be designed to repre- 
sent any magnitude response the 
designer chooses. But they fall prey to 
the same problems that plague anyone 
who attempts a polynomial approxima- 
tion — quite a few terms may be needed 
to replicate every wiggle in J{x). 
Nbnetheless, the FIR filter provides 
some distinct advantages, including 



The FIR filter 
provides some 
distinct 
advantages, 
Including inheront 
stability and ease 
of design. 

inherent stability (because it's bounded 
by definition), ease of design, linear 
phase, and a group delay that depends 
upon filter length and symmetry. 

THE DIRECT APPROACH 

Illustrations of spectra are often used 
to explain how a filter works. Figure 1 
illustrates the frequency response of a 
low-pass filter that we might like to 
design. 

How can we derive filter coeffi- 
cients that will produce those results? 
Actually, it isn't as difficult as it may 
seem. We need* temember one of the 
most important dualities in signal pro- 
cessing, in which time domain impulse 
response and system (frequency) 
response form a Fourier transform pair. 
In other words, the Fourier transform 
of the impufeeseiponse of a system is 
the frequency response and conversely, 
the Fourier transform of the frequency 
response is the impulse response. If we 
have one, we can easily get the other 
by applying the transform. 

Figure 1 is an illustration of the fi-e^ 
quency response of a proposed FIR 
low-pass filter. To get the impulse 
response (the filter coefficients), we 
simply need tQ.perferm a Fourier trans- 



form on the data in the illustration. 

Unfortunately, you cannot collect 
the data fi-om a graph of magnitude 
response, because these graphs are 
almost always of squared magnitude 
response, or the result of a transform in 
which the absolute value of the magni- 
tude was taken for the plot. We cannot 
know whether a particular value is pos- 
itive or negative by looking at such a 
graph. But let's pretend for the 
moment that you have access to the 
values used to prepare the plot (as I 
do), and we can collect the data from 
the graph. See Table 1 . 

The plot in Figure 1 was actually 
created by taking the absolute value of 
the data in Table 1. With this informa- 
tion, we can take the inverse transform 
of these magnitudes to obtain our filter 
coefficients. Figure 2 presents a plot of 
the result of this inverse transform. 
This plot is the impulse response of the 
proposed filter and a table of the filter 
coefficients (Table 2). 

Figure 2 is a plot of a function of the 
filter coefficients derived from the 
inverse transform. Some will recognize 
it as a function that we have mentioned 
before and will run into time and time 
again in filter design — the sine func- 
tion. Mathematically, it is defined: 

7TX 

Plotting a simple graph of this func- 
tion reveals that it possesses the fol- 
lowing properties: 

siiicO = 1 
sin cn = 

and: 

/ micxdx = 1 

J —oo 
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HGUREI 

niustratian of the frequency response of a desired low-pass filter. 




TABLE 1 

Frequency response of desired filter. 




The sine function possesses the 
interesting spectral character of con- 
taining all frequencies up to a certain 
limit and none above. You may recall 
from previous discussions that this is 
similar to &e sampling function used 
to determine tiie impulse response of a 



system. The narrower the fiinction is, 
the higher the frequency components it 
can measure. In the illustration, note 
that the general appearance of the sine 
function is similar to an impulse. 

The sine funcHcd forms a transform 
pair with the box ftinction in the fre- 
quency domain. Essentially, our low- 
pass filter is a box whose origin coin- 
cides with the origin of the spectrum. 
We call this an ideal low-pass filter. It 
expects minimal deviation in passband 
and minimal deviation in the stopband 
and a sharp transition band — thus cre- 
ating the box. 

But let's not obscure one of the most 
important results of this transformation 
and discussion. The formula for the 
sine fimction provides us with a closed 
form for the calculation of filter coeffi- 
cients from known parameters. We do 
not need to pursue the transforms for 
our answers; we need only know how 
many coefficients we want and what 
our cutoff and sampling frequencies 
are, and we can solve for the coeffi- 
cients. This is definitely one of the 
perks associated with a familiarity with 
the Laplace and Fourier transforms. 

DESIGN 

When we design a digital filter witii 
known parameters, we are defining an 



essentially infinite length impulse 
response with those parameters. When 
we use the Fourier series to design FIR 
filters, we are actually performing a 
least-squares fit in the frequency 
domain to a particular magnitude 
response, as we demonstrated at the 
beginning of this column. 

For the purpose of simplicity, we 
can state (for the time being) that the 
more coefficients, the better the filter 
approximation (as with Weierstrass). 
But because we can't support an infi- 
nite number of coefficients, we must 
truncate somewhere, giving us the 
number of coefficients. We'll also 
make a stipulation that we'll discuss in 
more detail later: these coefficients are 
symmetrical about a central ordinate 
that we calculate immediately, that is, 
the direct proportion of the cutoff fre- 
quency of the low-pass filter and the 
Nyquist frequency. 

We can determine the coefficients 
that will express this impulse response 
by integrating: 

This is the kemel expression for the 
Fourier series. We are solving for the 
Fourier coefficients that will allow us 
to expand this magnitude response in a 
Fourier series. The Fourier series can 
be shown to produce the best least 
squares approximation in a Hilbert 
space. 

Because it is an approximation, we 
also have an error term which repre- 
sents the difference between the actual 
continuous time function and the digi- 
tal representation. Let us show this as: 

A{ej^) - A[eJ^}^a{n) - a[n] 

Let's call this error term s, and define 
it as: 

and: 
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^|a(n) - a[nf = , 



The above is given here as signal ener- 
gy in flie form of Parseval's Theorem. 

As the error is minimized by using 
the orthonormal spectral coefficients 
produced by the integral (see Equation 
1), the error term is orthogonal to the 
approximation. In fact, they form a 
direct sum, and because the error 
would be zero if the approximation 
used all basis functions (as, if it were 
infinite, tiie integral would), it stands 
to reason that the more basis fiinctions 
used, the smaller the error term will be. 
Remember our previous statement: the 
more terms we use, the better the 
approximation. 

The ideal low-pass filter has a fre- 
quency amplitude response, as follows: 



forp\<n, 

/or n^<|n|ar 



Using the formula, we can calculate 
the necessary coefficients for our low- 
pass filter. How do we do this? Let's 
start with an abbreviated derivation. 
We will use the Fourier series to 
approximate the desired magnitude 
r^ponse: 



sm 



with 



' fs 



where is the sampling rate. The dif- 
ference between this representation of 
the sine function and the one presented 
earlier is that X has been replaced with 

I should offer a word of caution. 
What we derive with these coefficients 
is a non-causal filter. The sine fimc- 
tion, as you will note firom Figure 2, is 
symmetrical around zero, which means 



FIGURE 2 

Plot of the impulse response of the filter characteristic in Figure 1, with the fil- 
ter coefficients. 




that we expect some output from our 
filter before there is an input. We must 
move the origin of our filter coeffi- 
cients so that they all occur after time = 
0. The causal impulse response will be 
a simple shift in ^msm' 

fc(rt)=a(n-^^), n=0,1.2,3...Ar-l 

We can find filter coefficients for 
other forms of ideal filters as well, 
using these formula: 



highpass: 

a{ny 



sin(ni2c) 



nn 



bandpass: 

_ sin(«Qc;,) - sin(«Qc/) 



nn 



bandstop: 



a{n)= 



sm{nQ.ci) - sin(HQcA) 



nn 



USING THE FOURIER METHOD 

In the digital domain, filter parameters 
such as passband, stopband, and cutoff 
frequencies are all related to &e sam- 



TABLE2 

Figure 2 filter coefficients. 

0.00861451 
0.0106022 
0.00612134 
-0.00358194 
-0.0137832 
-0.0180861 
-0.01 13682 
0.00748951 
0.0344581 
0.0614927 
0.0795775 
0.0823817 
0.0689161 
0.0439234 
- 0.0159155 
-0.00633728 
-0.017229 
-0.0161823 
-0.00723432 
0.00329539 
0.00984516 



pling frequency. In fact, they form a 
proportion. Let's say that we wish to 
design a simple low-pass filter with a 
cutoff frequency of lOKHz {fs = 
lOKHz). This number means nothing 
without the sampling frequency, which 
in Ibis ease will be 48KHz (f^ = 
48KHz), making the Nyquist firequen- 
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cy 24KEIz. We choose a value for the 
number of coefficiente and calculate: 

0.0 

0.046774464189431999 
0.100910230485421004 
0.151365345728131455 
0.187097856757727836 
0.2 

0.187097856757727765 

0.151365345728131339 

0.100910230485420893 

0.0467744641894319101 

-0.0 

This technique produces good results, 
closer to the ideal low-pass frequency 
response as the number of coefficients 
increases. It has the drawback of a 
large passband and stopband ripple, 
resulting from a truncated Fourier 
approximation. The drawback is 
known as Gibb's phenomenon and can 
be solved (or at least ameliorated) with 
a number of techniques, including win- 
dowing and finite transition banding. 
We will pursue those subjects in future 
columns, in addition to other closed 
and open forms of FIR design such as 
Parks-McClellan and the Lagrange 
approximation: 

AS A PROGRAM 

Now let's look at what is required to 
write a simple program to solve for the 
coefficients we've described. The list- 
ing I've provided presents a short bit of 
code meant only to demonstrate the 
process involved. Much of the accom- 
panying program (available from 
http ://www . embedded . c om/code/htm) 
is involved with file handling and 
some mild error detection. You will 
need to provide certain command line 
parameters to the routine so that it can 
solve for the coefficients. If you don't, 
a short screen will remind you of the 
necessary parameters. Very little error 
correction is performed on the data you 
provide. 

There are a few variables that are 
important to the computation of the fil- 
ter coefficients. The variable coef 
defines the nimiber of filter coeffi- 
ciieats; Icutof f sets the cutoff or comer 



In the digital 
domain, filter 
parameters such 
as passband, 
stopband, and 
cutoff frequencies 
are all related to 
the sampling 
frequency. 

firequency for the low-pass and high- 
pass filters. Finally, hcutof f is used in 
the bandpass and bandstop filters for 
the upper cutoff point. Note that Icut- 
off and hcutoff are normalized to 
Nyquist. (This simple divide represents 
the integration of the function from 
zero to 7t.) 

Next, the core of the program is 
given in the case statement: 

switch (lambda) { 
case 0: //LOWPASS 
vector [coef /2] ' = hcutoff ; 
//central coeficient is nornialized coef 
ford = 1; i<coef/2; i++) { 
//write both halves of sfmetrkaL filter 
//at the same tine 
vector [coef /2+i] = vector [coef /2-i] = 
sin(vector[eoef /2]*i*PI)/(i*PI) ; 

} 

case 1: //HIGHPASS 
vector [coef /2] = hcutof f -Icutof f; 
//central coeficient is normalized coef 
for(i = 1; i<coef/2; i++) { 
//write both halves of syimietrical filter 
//at the same time 
vector [coef /2+i] = vector [coef /2-i] = 
(sin(hcutoff*i*PI)- 
sin(lcutof f *i*PI))/(i*PI) ; 

} 

break; 



case 2: //BANDPASS 
vector[coef/2] = l-(lcutoff); 
//central coeficient is normalized coef 
for(i = 1; i<coef/2; i++) { 
//write both halves of symmetrical filter 
//at the same time 
vector [coef /2+i] = vector [coef /2-i] = 
-l*f abs (sin (vector [coef /2]*i*PI) 
/(i*PI)); 

} 

break; 
case 3: //BANDSTOP 

vector[coef/2] = l-(heutoff-lcutoff); 

//central coeficient is normalized coef 

ford = 1; i<coef/2; i++) { 

//write both halves of symmetrical filttr 

//at the same tine 
vector[coef/2+i] = vector [coef /2-i] = 
(sin(lcutoff*i*PI)- 
sin(hciftoff>i?L*PI))/(i*PI) ; 

} 

break; 
default: //WHO KNOWS?? 
printf("\ndon't know that filter 

function..."); 
exitO); 

} 

The variable lambda is a value that 
selects the proper coefficient deriva- 
tion scheme, coef is the nxmiber of 
desired coefficients, and vector is the 
output. The program produces the 
coefficients distributed correctly for afl 
odd-length symmetrical filter. 

MORE TO GOME 

Next month we'll discuss even and odd 
filter lengths and the difference 
between them. We will also introduce 
another closed form for developing fil- 
ters (the Lagrange approximation) as 
well as some code for using the coeffi- 
cients you develop. 1^3 

Don Morgan is senior engineer at 
Ultra Stereo Labs and a consultant in 
signal processing, embedded systems, 
hardware, and software. Morgan is 
currently completing a book about 
numerical methods, featuring multi- 
rate signal processing. He is also the 
author of Practical DSP Modeling, 
Techniques, and Program-ming in C 
(Mhn Wiley & Sons, Chichester. U.K.). 
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on one CD! 



Release 2.0 includes the entire history of Embedded Systems 
Programming from 1988-1996 and the premiere 1996 Buyer's Guide 
issue with information on over 1,100 products. Over 98 issues 
including full text, source code, buyer's guides, and product 
demonstrations not found in the m^azine are packed on one CD. 
All of your favorite columnists including Jack Crenshaw, P.J. 
Plauger, Jack Ganssle, Tyler Sperry, and Bruce Eckel are included. 
You now have the ultimate embedded development resource at 
your fingertips for just $79.95! 



Guides 



SOURCECODE 



Product Demonstrations 



The Ultimate Time Saver! 

Imagine you ore having trouble utilizing a 
processor's memory management unit ' 
( MMU) in your embedded design. Just put 
the Embedded Systems Programming Library 
into your CD-Rom, launch a search for 
"MMU", and presto, a slew of articles with 
valuable programming code on the subject. 
An intuitive user interface and potent search 
engine guides you in finding the information 
3U need. Access nine years of back issues by 
Itle, author, month, year, or use a custom , , 
'ord search to locate exactly what you neecHH 
p directly to the information vou want.TlH 
I cut and paste what vou need to your I 



.9^ 



I 



Order Today! 

1-800-444-4881 
Fax: 913-841-2624 

E-mail: orders@nifi.coni 
MaiL Miller Freeman, Inc. 
1601 West 23rd Street Suite 200 
Lawrence, KS 66046-2700 
: CD Rom Order Processing 



|al Features! 

i/ Powerful text and Boolean search engine 

✓ Over 800 articles, reviews, and editorials 

✓ Buyer's Guide information on 1,100 
products spanning 16 product categories 

✓Copy valuable programming code 

directly into your designs 
✓Access to over a million words 

✓Product demonstrations and 
links to the Internet 

✓Ck>py, bookmark and notes fimctions 

✓Windows/Mac/Unix-based CD-Rom 
with a robust search engine 



I want this CD! 

only $79.95 (+ shipping and handUngV 



Name (Please print clearly) 


Address 


City/State/Zip/Country 


Phone 


email 


Credit Card Number 


Exp. Date 


signature required 


•Shipping is $3.50 US/Canada; $15.00 all 


Check one: 


other countries. California ($6.80), New York 


□ Visa/MC aAmtx □ Check enclosed ($6.60), Texas ($6.60), Illinois (SS.nO), Kansas 


Check one: 


($5.50), and Georgia ($4.80) residents should 


□ 1996 CD-Rom ($79.95 + shipping) 


add sales tax. 


□ Upgrade from previous edition 
($29.95 + shipping) 


Clip out or photocopy this form. 
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At CellNet, we ore Itie worid leader in wireless data communications systems and 
services which we provide to industnes facing sweeping changes. Our system, with 
its sophisticated network of hardware and softwore, offers reol-time customer infor- 
mation to our clients, helping them thrive in a dynamic, competitive moHcetpbce. 
If you are an experienced pidessiond, send us your resume todoy! 

Embedded Systems 
Software Engineers 

In this position, you will design and develop fast, robust, real-time distributed 
applications, embedded systems infrastructure, and device drivers. Requires 
BS/MS in EE/CS and 2+ years of experience with embedded system 
design/implementation using C / Q++ and assembly language. Experience wift 

real-time OS, UNIX®, telemetry, STREAMS, wireless datocomm 
, 683xx, DSP, and radio systems are all pluses. 



We offer a challenging woHc environment competitive salary, and a comprehensive 
benefits pockoge. For immediate consideration, please send your resume, indicot- 
ing the position of interest, to: CellNet, Professional Staffing, 125 Shorewoy Rd., 
San Carlos, CA 94070. FAX (415) 508-6880. E-mail: Careers@cellnet.com 
(ASCII only). EOF /HI tmdmaria belong lo Itiei lEspeclive companies. 




CellNet 




A WORLD OF OPPORTUNITY 
IN COLORADO!! 



i Y S T E M ! 




ENSCICON CORPORATION CURREPiJTLY 
HAS SEVERAL POSmONS OPEN: 

REAL TIME, EMBEDDED SYSTEMS 

• Controls 

• Servo's 

• Signal Processing 

• User Interface 

• Algorithm Development 

• C, C+-I-, Assembly 

• Real Time Embedded Software Quality Asswance 
Rush Your Resume To: Reference Job #RT100 

ENSCICON CORPORATION 
1775 SHERMAN ST., STE. 1700 
DENVER, CO. 80203 

FAX (303) 832-6700 
PHONE (303) 832-8200 
EMAIL: info@enscicon.Gom 
web: www.enscicon.com 

ENSCICON CORPORATION IS AN EQUAL OPPORTUNITY E.MPLOYIiH 



TO LEARN MORE ABOUT OUR PRESENT 
OPENINGS, VISIT OUR WEB SITE AT: 

http://www.cellnet.com 



Bis, M 
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Advertise in tlie 
Embedded Systems 
Programming Career 
Section! 
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WEST 
Robin Lander 
415.278.5274 



EAST 
Ryan Soriey 
617.235.8255 



EMBEDDED GALLERY 



Tools For Embedded Developers 



Software Tools 



Micro Web Server Solution 

Based on Internet standards and Java 
technology, Embedded Micro 
Interface Technology (EMIT) enables 
the use of a Web browser to configure 
and manage electronic devices over the 
'Net or a direct connection. It is the 
first scalable micro Web server solu- 
tion that makes this technology avail- 
able to even the smallest electronic 
devices, such as the 8051. EMIT 
requires only 750 bytes of ROM and 
28 bytes of RAM on the device, and 
includes pre-written software for most 
common device controls. A single-user 
EMIT 1.0 Software Developers Kit 
with 10 embedded licenses is $1,200. 
A company site license with 10 
ernbedded licenses is $3,000. 

EMIT 1.0 

emWare 

Midvale, UT 

(801) 256-3883 

READER SERVICE NO. 115 



GO Development Tool 

OljjecTime Developer 5.0 is an object- 
oriented (00) toolset designed for 
management of the entire development 
cycle. The OO toolset enables develop- 
er^ to build graphical models of their 
designs and observe these models on 
development and target platforms. The 
executable modeling capability aids in 
the development of real-time designs, 
as the graphical models are animated at 
every stage of the development life 
cycle. 

ObjecTime Developer 5.0 adds 
code-generation support for Wmdows 
NT 4.0 and Wind River's Tornado for 
PowerPC and 68K, and now supports 
oVer 30 target combinations. A floating 
license is $25,000. 



ObjecTime Developer 5.0 
ObjecTime Ltd. 
Kanata, Ontario 

(613) 591-3535 

READER SERVICE NO. 116 



Management Tool 




The RequisitePro 2.5 requirements 
management tool adds integration with 
the Rational Rose visual modeling 
tool, and Microsoft Visual SourceSafe, 
a project-oriented version control tool. 
This integration makes it possible to 
trace end-user requirements from their 
origin through implementation and to 
manage changing requirements along 
with changes to the software source 
code. RequisitePro integrates into the 
leading application development tools 
used to define, model, manage, and test 
software. A single workstation license 
is $1,295. Concurrent licensing is 
available in quantities of 10 or more 
starting at $2,995 per license. The 
upgrade is free to RequisitePro cus- 
tomers with SupportPlus. 

RequisitePro 2.5 
Rational Software Corp. 
Boulder, CO 

(303) 444-3464 

READER SERVICE NO. 117 



Development Environment 

The MULTI Development Environ- 
ment is now available for the CHO- 



RUS/ClassiX real-time operating sys- 
tem from Chorus Systems. Green Hills 
development tools, including C and 
C++ optimizing compilers, tool chains, 
utility programs, and the MULTI 
Development Enviroimient, can be 
used to develop and debug multi- 
threaded applications supported by 
CHORUS/ClassiX from application 
code level to kernel execution level. 

Microprocessor families currently 
supported include the 68K, PowerPC, 
and SPARC II. The package, includ- 
ing a C compiler and development 
environment supporting CHORUS/ 
ClassiX on a Unix host, is $7,900. 

MULTI Development Environment 
Green Hills Software 
Santa Barbara, CA 
(800) 500-2580 

READER SERVICE NO. 1 18 

Chips 



USB 8-Bit Microcontrollers 

New additions to the 68HC05 family 
include the 68HC705JB2 and 
68HC05JB2 microconfroUers for low- 
speed Universal Serial Bus (USB) 
computer mouse applications. Each 
chip has an on-chip memory of 2,048 
bytes of user ROM (or EPROM) and 
128 bytes of user RAM. The device 
also offers 16-bit input capture/output 
compare timers and is designed to 
comply with low-speed USB with 
three endpoints. The 68HC705JB2 
(EPROM) with voltage regulator is 
$3.50 for pilot production volumes. 
The ROM-based 68HC05JB2 is $1.40 
in high volume. 

68HC705JB2/68HC05JB2 
Motorola CSIC BivWoft 
Austin, TX 

(800) 765-7795 ext. 887 

READER SERVICE NO. 1 19 
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BFGoodric:h Aerospace - Aircraft Inlegratcd Syslcms is a (iyiiainic m,in(il.ii.inrer nl 
state-of-the-art electronic performance systems lor the aerospace industry. Business 
growth and internal promotions have created excellent opportunities for Software 
Engineering Professionals at our Vermont location. 

Located near Burlington - ranked #6 by Reader's Df^St's "50 Best Places to Raise a 
Family," and cited as one of the 7 "Dr^m TowrS" by Outside Magazine - our area 
offers outstanding recreational opportunities and muoi more. 

SOFTWARE ENGINEERS 

Embedded Systems 

Design, code, lest and integrate real-time embedded software and conduct design 
reviews. Programming languages include C, C+-i- and Ada [Ada training will be pro- 
vided if necessary]. Experience with large project design, CASE, OOA/OOD, and 
software reuse is preferred. 

BFCoodrich Aerospace offers competitive salaries and a comprehensive benefits 
package. Please mail, fax or e-maii your resume to: 

Employment Manager 
BFGoodrich Aerospace 
Dept. EE 
1 00 Panton Rd. 
Vergennes, VT 05491 
Fax:(802)877-41 11 
E-mail: bfgcmpl@aisvt.bfg.com 



IFGoodrich 



Aerospace 

Vergennes, VT 



BFCoodrich Aerospace is ari equal opportunity employer m/f/d/v. 



TRW Automotive Electronics 
Farmington Hills, Michigan 



Embedded Systems 
Opportunities 

Put your energy and creativity to work for 

the leader in state-of-the-art automotive 
electronics R&D and manufacturing. IRW 
seeks individuab who desire a broad scope of 
responsibility, career growth opportunity and 
a dynamic enviroivment. 

• Project Managers 

• Software Engineers 

• Hardware Engineers 

• Individual Contributors 

Develop systems for state-of-the-art crash 
control, electronic steering, and convenience 
systems. Desired experience includes C coding, 
and assembly, algorithm development, embedded 
microcontrollers, and sensor systems. BS EE/MS 
EE and 2 or more years experience preferred. 

TRW/AEG offers Fortune 100 level compensa- 
tion and benefits and excellent relocation 
assistance. Respond to TRW; c/o Myers & 
Associates; P.O. Box 238; Allen TX 75013- 
0238; Fax 972-390-1329; E-mail 
TRWJOBS@aol.com. 

★ Check out our Web site at 
WWW.ALPHA-USA.COM/TRW-J0BS. 



An Equal Opportunity 
Employer, M/F/D/V. 
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EUROPE 



Please visit! For advertising opportuiiities, call Marcv Walpert at 415.905.2348. 



PicEm-14('"'> 

Low cost PIC Downloader 



80C186 

In-Circuit Emulators 



To find out more about the products and 
services displayed here, circle the 

corresponding Reader Service number 
on the response card bound into this 
issue. Each advertiser will send you 
more information free of charge! 



Embedded Marketplace is a special 
showcase section reserved for advertis- 
ers with standard 1/9-page display ads (2 
1/4 by 2 inches). For information on 
placing an ad in Embedded 
Marketplace, call Robin Lander (415) 
278-5274 or Ryan Sorley (617) 235- 
S255. 




' Flexible single 

board design 
emulates 14 bit 
PIC devices. 
' Downloads from 
any serial port. 



Configuration examples: 
■PICEM 14-622 for16C62x $295 
'PICEM14-74A for 16C6xA, 7xA $325 

NO additional add on boards required 
Upgradeable to other PIC 14 bit devices. 
Call for details, or check our web site. 

Microsystems Development, Inc. 
4100 Moorpark Ave. #104 
San Jose, OA 95117 
(408) 296-4000 
http://www.msd.com/picem 



100% PC/AT Cmfulible 
IIH Hill 66, 100, U3 MHz 

,,1. .. nil, ,,11,1 111,1 CI 16BilPC/I04lf 

at and m If 
COMI, COM2, LPT 
I EmbeiUeil Sysim BIOS 

flash File System 
&6 WalcMag Tmer 

_ Remote Console Mode 
Q i= fast Bool / Oark Boot 

Operat. Temp. -70 

Call / Mail lor yoor fRCC MNUAl and inlomalion aboal oar other 
PC/ 104 products. Soon we will start a representing oftitein San JoseCA. 

Heislerbergollee 72 PC/104 ProJatts: 386EX tAHianlrahr 
30453 hmnom / eermony ' CAH Canlrolki fCMCIA Oigitol l/l>_i 



fOII-.t-t 49 511/40 000-0 
Ml'+ff? 5(1/40 000-40 



kllf. //mmil] .ie/si/pim ^^^^ ^^^^ ■] 

SSP Hmo^erc'i onlmc rfc SOFTWARE SYSTEMS GmbH ; 



In-Circuit 

EMUL166^PC ^ Emulator 
Real-Time Microprocessor 
Development Tools 

Call (408) 866-1820 for a product brochure 
and a FREE Demo Disk. 
Information is also available via Fax, call our 

24-hour Fax Center at (408) 378-2912. 
Visit our web site- litlp://www.nohau.com 

See EEM '97- pages D 1274-1282 

MM^J^«| I 51 E. Campbell Avenue 
I lUnCIU Campbell, CA 95008-2053 

CORPORATION Email: sales@nohau.com 



In-Circuit Emulators 
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8019B • 8051 • 80186 • Z8 
DSP • HPC • 8085 • Z380 



REAL-TIME IN-CIRCUIT 

BBMIGGIN6& DEVELOPMENT 

ON-THE-FLY ACCESS TO 
PROGRAM AND 
DATA MEMORY 

REAL-TIME 
TRACE FIITERIHR 




WINDOWS 
& MOUSE 
USER INTERFACE 

FREE USER SUPPORT 
EXTERNAL UNIT WITH NO PLUG-IN CARDS 
OUTSTANDING PERFORMANCE AT A REALISTIC PRICE 




irK~\ D f 0" MORE INFO on TO ARRANGE 
/ / I y / / YOUR 1 DAY FREE TRIAL, CALL: 

'^^y 1.800-838-8012 




CIRCLE* 



® Advin 




PILOT-U84-rtiis Universal Programmer 
#i in Expandability 

* S/W expandable, free updates via BBS 
* True low voltage support • Gang expandable 
* Package type expandable: PLCC.QFP.TSOP, 
SOIC, PGA,BGA,etc. * Many other models 
* Absolutely Positively Guaranteed. 
800-627-2456, 408-243-7000 
FAX: 408-736-2503. www.advin.com 
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Small, Smart 
& Analog 
Ready! 



Z-World's powerful 
BL 1500 controller is 
ideal for OEM 
machine control and 
data aquisition, 
especially when 
analog I/O is 
required. 

Our Dynamic C^' 
software (editor, 
compiler, and 
symbolic debu^er) 
makes your system 
development easy. 




BL1500" 

From $119 m\ 



m 4 analog Inputs 

■ 26 parallel I/O lines 

■ Real time clock 

• SRAM/Flash EPROM 

■ RS485/RS232 

• Watchdog timer 



INNOVATION IN CONTROL TECHNOLOGY 

For a FRF.F, catalog and 
more information call... 
916.757.3737 
9I6.753.5l4l FAX 

UprREADER SERVICE CARD 
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A-Corei"& A-EngineT 



DEVICE PROGRAMMERS & 

MEMORY TESTER 




20Mhz wait state emulation • 1 15k baud serial down- 
loads = 10.5k/sec • 128k to 1MB write-protectable eraula 
tion RAM • 1 MB execute, mem r/w breakpoints • 1 MB 
address monitor. • Features: High-powered Tuibo-de- 
bi^-Uke souico-level debugger • Debug C and assembly 
code • Watdi/iinpect/modily an; C Taiidik indiiding 
stnicts • ZSO l unhwuB tt Z180 MMU banked pngiam 
aiqiport •Dot rifM and ^end tea - Fb yew bHffJaal 



ZSO Z180 Z181 ZiaS BOSS 

ANSI C Compilers and macro assBmblara 



★ BOO-5Sa-5SOn * 
B60-S3B-<!lS01/4S0S/430a 

WWW. Softools. com CSalacs/C A V/RRQ 

info@softools.com Sales/FAX/BBS 
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683xx 

Real-Time Debugging 



Intelligent debug 
hardware 
Advanced high 

level debugger 
68332, 68340, 
68360, 68328 etc... 
2.7 to 5.5V 
High speed comms 
No plug-in cards 
1 2 months warranty 
$1695.00 complete 

Call 508-647-0103 
to arrange your 

free evaluation 




Accelerate Firm war 
Development 



with TechTools. 



EconoROM II 



Economical EPROM 
^ Emulator 

w/ Read-back, 
verify & Self-test Functions 

EconoROM //continues our reputation of High-speed, 
Reliable, Economical EPROM Emulation by adding new 
features without raising the price. 

• Fast Download 
(i.e. 51 2Kbit file in 2,5 seconds or less), 

• Fast 90ns & 45ns access times, 

• Read-back, Verify and Self-test Functions, 

• Full-screen editor plus batchable loader & utilities 
included. 

• 4//sizes and speeds can lie Daisy-chained 
togetiier and individually addressed from one port. 

• Memory retention for true power-up emulation. 

c^wm $Ji-9.Q0 

8 bit & 16 bit Models avaiiable up to 4 Mbit 



■MTTin PRICES START AT 
Bm $79Qty1.$280EM 

• High Performance, Compact, Reiialiie 

• Easy to program in Borland/IWicrosolI C/C++ 



I 




3,6-i2 3"A-Engine" 

AMD18SES. 

50+IO 

11 12-bit ADC 

3UAFITs.3limers 
2 PWM, BattRTC 

C library 

Development kits 



We have 20+ Low Cost 1 6-bit Controllers with ADC, 
DAC, solenoid, relay, PG-104, PCMCIA, LCD, DSP 
motion control, 10 UARTs, 100 l/Os. Customer 
boards design. Save time and money. 



^1 



216 F Street, Ste. 104, Davis, CA 9S6I6, USA 
-T^ppXT fel: 916-758-0180 • Fox:916-758-0181 

JNC. ^'wmf tern@netcom com miSm 



FlexROM II 



FLASH/EPROM 
Emulator 



' Address Snap-Shot & 
Trigger Circuit. 

A FAST FLASH and EPROM Emulator with the fc^lowing 
Standard features included: 

• Target Write-bact<, • Arbitration support, 

• Daisy-chain port for multi-unit operation, 

• Fast Download (up to 2,5 Mbit per second), 

• Fast 90ns & 45ns access times, 

• Full-screen editor plus batchable loader & utilities, 

• C Library • On-The-Fly editing. 

• Snap-Shot circuitry captures the target's most 
recent access. 

• Trigger circuitry generates a trigger each time the 
target accesses a user-specified address, 

^■roiii $SW.0O 
8 bit & 1 6 bit Models available up to 8 Mbit. 




Save up to 80% over MS-DOS" 

A fully compatible, 
ROMable DOS for 
embedded systems 



FREE DEIVIO DISK 

1-800-221-6630 

Datalighf 

18810 59th AVENUE NE • ARLINGTON, WA 98223 
(360) 435-8086 • FAX: (360) 435-0253 




Noral Micrologics, Inc. 

Tel: (508) 647-0103 
Fax: (508) 653-1828 
harrye(gtiac.net 
http;//vvww.noral.com 



UniROM 



No-impact 

"LIVE" 
Emulator 



t niROM not only emulates EPROM. Flash and SRAM, but 
also adds hardware assisted debugging, Live editing, Live 
Watches and a robust library for custom applications. 
L ViiRO.M is ttte only Memory Emulator that allows real- 
time 'Live' editing and monitoring with zero impact on the 
target system. 

• Device Emulation 
• Hardware Enhancement for Software Debuggers 
• Manufacturing / Acceptance testing. 
• Real-time monitoring and control applications 
• Supports new processors and ASIC-based 
microcontrollers. 

(^tom $595.00 
Dual 8/16 bit Models available up to 32 Mbit 



Details on the WEB: 
http://vv^\w.tech-tools.com 



Embedded 

Systems 
Development 
Tools 



Call: (972) 272-9392| 

FAX: (972) 494-5814 
sale$@tech-tools.com 



• Emnlates 2716 to 27080 in a Single Unit 

• CascadaUie for More Memoiy. 

• Selectable Word Sizes. 

• Uses PC Parallel Port for Fast Loading. 

• Batleiy Back-up for Stand Akoe Openticn. 

• Easy to Use Complete Intenctive Software. 

• PLCC Adapters Available. 

As Always, Unoonditiaiial Money Back Guarantee. 

RomEm w/1 M^bit (128Kx8) . . . .$395.00 

RomEmw/4 Megabit (5 12Kx8) $695.00 

RomEm w/8 Megabit (1024Kx8) . . .$995.00 

j.^-^.^ 4100 Moorpark Avenue #104 
iJ-^N jj San Jose, California 95117 

(408) 296-4000 Fax: 408-296-5877 

http;//www.m8d.con/romen 



CIRCLE #75 ON READER SERVICE CARD 



New High-Performance 
486 Emulator 

"This new in-circuit emulator shows software and 
hardware events that are invisible with any other tool 

Microtek Emulators available for: 

Pentium" • Intel486~ • NS486" 
Intel386~EX • 386DX • 386CX/SX • 80C186 

68360 • 68340 • 68F333 • 68332 
68331 • 68330* 68HC16 

To find the solutions to your problems, call us t( 
1(800)886-7333 
(503)645-7333 Fax:(503)629-8460 
E-Mail: info@microtekintl.com 
Web: vtfww.microtekintl.com 



MICROTEK 

iN-CiRCUfT Emulators 



CMX-RTX™ RTOS 



Source Code Included • NO Royalties 
80x51 •80S1-XA*80C251 
80196/296 • 80x86 • Z80/180 
80C1 65/1 66/1 67 • ST9 • STIC 
68HC11/12/16 • 68K • 683xx 
H8/300H • TLCS-900 • ARM 
M16C • SH • PowerPC &.More 

Available NO W! 
CMXBug for Windows 
CAN Communications Layer 



Compilers Simulators Debuggers 



Available for most of Ifie above processors 
Including 68HC05 & PIC16/17 



CMX 

COMPANY 



Phone: (508) 872-7675 
Fax: (508)620-6828 
e-mail: cmx@cmx.com 
WWW: vvww.cmx.com 

5 Grant Street • Suite C 
Framingham, MA 01702 USA 
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Fast. Reliable. Affordable. 



Parallel port 
EMP-ia 
S219.95 



Parallel port I 
mp-20 " 
$149.35 



IM'S DEVICE PROGRAMMERS are the easiest and most 
cost-effective way to read, program and verify 271 6 - 8 meg 
EPROMS. Support for Micros, Flash, EPROM, 16-bit, PLDs, and 
Mach (call for support list for specific models, or download demos 
from our BBS or web site). Easy to use menu driven software 
features on-line help, and a full-screen editor. Support for 
macros, read and save to disk, and split and set options, 

• Free technical support • Free software upgrades 

• 1 to 2 year warranty on all parts and labor 

• 30-day money-back guarantee * Made in the U.S.A. 

• All models include software, on-line help, cables, and power 
transformers (where applicable) 



(916) 924-8037 



NEEDHAM ELECTRONICS, INC. 

4630 Beloit Drive. #20, Sacramento, CA 95838 

FAX (91 6) 924-8065 • BBS (91 6) 924-8094 ^9 '')mSm 
(Ivlon, - Fri, 8 am - 5 pm, PST) http;//www.neGdhams.coni/ 



It's hard to compete 
without the right tools 



american 
arium 



(714)731-1661 • www.arium.com 

Pentium arti Pentium Pro are registered trademarte of Intel Corporalion. 
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EPROM EMULATORS 



e 



A 



El up to 12aKx8 
E4 uptoBtSKxB 




?■ Full Simulator. ROM Monitor and ICE versions 
7- Turbo Debug Power plus Windows ease-of-use 

Call for a Free Demo Disk or 
Visit us at: ww^^i^hdptools.com 

905-274-6244 

FAX 905-891-2715 



Ch/pTools 
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BASIC Stamp II 

EEPROM-Based Module Runs 
BASIC Programs Written on PC 



♦85ns and 35ns standard access times 
♦.^V LV models nperuie al 3V and 5V 
•High-speed d>nvnioiidiiiy (LPTl-3) 
with error checking and correction 
♦Loads binary, Mot-S, Intel 

• I'tiwer-up emulation 

♦(. o[np;ict size, with protective case 
•1 ou power design. 5mA max. 

• Snn\^ :ire eonfisiiirable 



I 



SDI 



Prices 
El-85 $l9m 
E4-85 $249 

El-35 $229 
E4-35 $299 

A-PL.CC $hf 



ElLV-90 S229 
E4LV-90 S299 




SCANLON 800 352 9770 

DESIGN (902)425-3938 Int'l 
INC. (902)425-4098 FAX 

nlernet: 7 1303. 1435 'A Compuserve. com 

;,22A Blowers St. Halifax, N S, Canada B3J 1J7 



Includes 

BASIC Commands 
For: Pushbuttons, cycle counting, X-10, PWM, 
potentiometers, serial data, pulse generation and 
measurement, external stiift registers, etc. 



(916) 624-8333 

i://www.parallaxinc.com 



Please try our FaiBack 
system at (91S) 624-1X9. 
Request docameni t60B2. 



The Worlds Most Powerful 
1 1 Portable Programmers 




Dataman-48 

Pmsmart® technology means true no-adapter programming up to 
48-pin DIL devices. Connects to your PCs or laptop's parallel port 
Library contains over 1500 of the most popular programmable 
devices. We even inclMde a 44-pin universal PLGC adapter. 

^'~*~*% Dataman S4 
. ~ Capable of programming 8 and 16-bit 

^> EPROMs, EEPROMs, PEROMs, 5 & 1 2V FLASH, 

Boot-Block FLASH, PICs, 8751s and more. 
Emulates ROM S RAM as standard. Complete 
with all emulation leads, organizer-style 
manual, AC charger, spare library ROM, both 
DOS and Windows terminal software, and 
arrives fully charged and ready to go! 



Tel: 800 328-2336 

Fax: (407) 649-3310 

www.dataman.com 



for more detailed information on these and other 
marlfet leading programming products, all now and 
request your free copy of our new color catalog. 




FREE upgrades & technical support 
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RECRUfTERS: 

WANT TO ATmACT THE BEST 
EMBEDDED DEVELOPERS IN 
THE INDUSTRY? 

Advertise in 
Embedded Systems 

Programming's 
Career Section! 




WEST 
Robin Lander 
415.278.5274 

EAST 
Ryan Sorley 

617.235.8255 



CiRCLE #87 ON READER SERVICE CARD 



PIC16 In-Circuit Emulator 




RieEl6 Emulator for lecsx/n with 8K R/T Trace .... $645^ 

• Run5 under DOS, Win5.x/P0S or Win 95 via para\\c\ port 

• Supports 16C5x/xx v\a device specific probe cards 

• SK program memory and &K real-time trace buffer 

• 12 external probes: break input, break output, trigger 
output and £> trace input probes 

• Source level support on MFAStvl, PASM/X, MFC, PCB/FCM | 

• Stepping, breakpoints and symbolic watch variables 

• Delectable internal fret^uencies or external clock 

• Comes with MFA5M, DOS and Windows 95 software 

• FlC single and gang, programmers also available 

• Made in the USA and CE-comp!!afTt 

Call 214-980-2960 or litiii://wwiiirjidiMraisAita.coni 

. ■ Pd., iiv^f. ■J.^ll-!',, I 7b244 Fan 214-960-2937 Email:atc1fflix.nt!tcom.con 

Advanced Transdata Cerporadon 



Save Time & Money ... 
Increase Functionality 



WUb Intel Matberbmrds & Platfarms for 
Ymr Real-Time & Process Control Designs 

Avnet Computer's OEM group is the only distributor 
sales force dedicated to helping OEMs build better, 
more cost-effective designs using high-qualit)' 
computer products. Avnet Computer supports its 
customers from design through production with 
leading-edge technical assistance from its team of 
engineers and with integration services from its 
Intel-certified integration center 

Eliminate/reduce design engineering costs. 

CtH for Details and a Free Amet Computer 
UneCard. 800-577-1078 



(k1 SjH'Cial I'rifiils 111! Q\X lii-il-Timi' OS 



Mel 
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ClearView Mathias 

In ' "-rulator for PICs 




ClearView Mathias is a complete Develop- 
ment and Debugging Environment for ALL 
16C5X and 16Cxx devices, featuring a 
programable oscillator, source-level debugging 
in Assembly & C, optional 16K Trace buffer 
with instruction timing / cycle counting, and 
upgrade modules for additional PIC members. 
Also includes CVASM16, TechTools PIC 
Assembler and Windows 3.1/95 software. 



http://www.tech-tools.com 

Voice; (972) 272-9392 
FAX: (972) 494-5814 
siilesfw tecll-tools.com 




Flex-4/104 



PC/104 
Multiport 
Serial Board 




• 4 asynciironous ports 
. 16550 UARTs with 

16 bytes of FIFO 
. RS-232, RS-485/422 
RS-423 & 20 mA 
interfaces 

• up to 115K baud on 
all ports 

• user selectable port 
addresses and IRQs 

Call today for more information: 

Connect Tech Inc. 

727 Speedvale Ave. West 
Guelph, Ont. Canada NIK 1E6 
Tel: 519.836.1291 Email: saleslgconneettech.com 
Fax: 519.836.4878 HTTP: //www.connecttech.com 



. PC/104 form factor 
I multiple boards can 
reside in a system for 
large applications 
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MIPS EMMORS 



In-Circut Emulation Support: 




R4«00 
R4650 
R4640 
R3081 
R3051 
R3041 
VR4300 

Source Level Debuggers 
Real-Time Full Speed 
32k Deep Trace 

• Hosts: Windows, Sun 4, HP 9000 

• Support and Training 

• Compiler, Assembler, Linker Available 



MICROTEK MICE for 8052, 8xC251,196 and PIC16F 




MICEpack Family 

• 6X302 series • 68306 

• PowerPC series • 6*307 

• gOC 186/1 8S series • CddFire 

• Ami 86EX series • 2Sl 

EasyPack Family 



)6 

iFire series ^^H^m^ 
series ^^H^k 



Call: 



Embedded Performance, Inc. 

I860 Barber Lare, Milpitas. CA 95035 

mips_ice @ episupport.com 
Fax: (408) 435-7970 

800-934-2466 




THINK EmMfljl! 

■]5DGn9 iN/iosi 



"The Embedded PC Specialists" 



4?% 




I ISA/PCI CPUs from 803865X to Pentium 200MHz 
I PROMDISK* Disk Emulator Boards support Rash, 

Eprom, and SRAM, up to 64MB 
I Chassis from 3 slot Embedded to 14 slot Rack Mt. 
I Full Line of I/O and Data Acquisition Boards 
I Bar Code Wand Scanners 



Net Address: 
www.mcsil.com 



E-mail: 
mcsi@mcsil.com 



2598 fortune woy 
vista, ca 92083 

760/598-2177 

tcu /60/59e-2d50 



ISA Bus or Standalone SBC 



I Drawing from our 1 5 years of experience 
I supplying reliable single board solutions 
we designed ISBS486, with a 486 or 5x86 
I CPU, to offer an optimal combination of 
I features, options, quality, and price. 

I Phone or fax for detailed information. 

Embedtec Corporation 

20045 Stevens Creek Blvd, Cupertino, CA 95014 
Phone (408)253-0250 Fax (408)253-8298 



Trace on-lbc-flv 
Qualified trace 

Pn. cata and post trigger tncc 
Triager Mi-thc-fly 

Mtmcffy nin-accew 
SoftwireMrtcmuBKe an«lyais 

♦Module a)uil>siA 

♦Tsne analyiis 

♦Code coverage 
L'scf defined rmrro and alias 
ShcU cooimaiK) auto-txpansiwt 
St^pcal C-cjf}M-csHioi! ill WaJeh Wmdow 
Finnwwe <kiwn!«nl c^abttity without factorv' iipgrnde 










»iC5UM»«C.M:Mat 

WM 

tMt 

nsi 

NB 


ttXfSH 

UCUI 

teaucuirk 

M3XI 

MUM 




Intel 






Winbonc 


w-«ci»-e 




Dallas 





For CPUs not shown, Please Contact Us 

Vcice: 408-955-0225 
Fax 40S-955-9705 
E-maiJ mice-sale@micrtek com 
Visit for Demo and Detail 

hftp; ''/www microtekinil. com 



MICROTEK 
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PC/104 SBC 



The Chickadee 




PC/1 04. 80C 1 88 CPU, up to 51 2K SRAM 
up to 51 2K EPROM/Hash, 8-ch 12-bit ADC 
16 TTL I/O, 7 relay drivers, 8 AC/DC Inputs 

2 counter/timers, real time clock 
LCD, keypad, RS-232, RS-23Z/485 ports 

6.50' X 3.55", 5V @ 70mA typiral 
Program with Microsoft or Borland C/C++ 
Frona $199 

^AGOTRONIXT 

Excellence in Analog & Digital Beclronics 

BAGOTRONIX ^ 
> 101 9 Crossing Brook Way , 
^ Tallahassee, FL 32311 / 
\ (9041 942-7905 / 
\ Phone & / 



ACE360 QUICC 

COMMUNICATIONS ENGINES 
Stand-alone and PC Bus Adapter cards 

• Motorola MC68EN360/MH360 QUICC 

• PRAM, Flash, & EEPROM 

• Serial Interfaces: RS232, RS530, V.35, RS422 

• WAN Interfaces: T1/E1, (SDN. TDM, TTL 

• Ethernet lOBaseT and AUI 

• Supports HDLC/SDLC. Transparent, UART 

• BDM and RS-232 Console ports 

• Custom OEM versions 

■ Bridging and Routing software avaitatile 



' ^TMirt'riii 






ATLAS 



(800) 224-1223 
(805) 898-2450 
Fax (805) 898-2452 
mfo@ace360.com 
http://www.ace360.com 




SERIAL 
COMMUNICATIONS 

MC68302 
Processor 

128KB 
RAM 



I 



USER PROGRAMMABLE 
UART/HDLC/BISYNC 

RS232/RS485 

I/O MAPPED 

ASYNC: 
115K, 230K, 384K 

SYNC: 1 Mbps 

OEM PRICING 



(352) 373-2626 
Fax (352) 373-7707 

(800) 232-0485 
www.rtcard.com 
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Advertise In the 
career section today! 



WEST 
Robin Lander 
415.278.5274 



EAST 
Ryan Sorley 
617.235.8255 
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BREAK POINTS 



by Jack G. Ganssle 



It s Done 



A manager likes nothing more 
than to hear "It's done." 
Unhappily, in the embedded 
world, "It's done" may be about as 
honest as "Sure, this is an alpha ver- 
sion, but it's ready for the market." The 
phrase simply means something differ- 
ent to everyone. The ultra-smart engi- 
neer might mean he has a pretty good 
idea about how to create the product A 
firmware builder generally means the 
code has been completely written — 
more or less. (Tested? Hey, that's just 
a detail!) 

At the risk of outraging you, gentle 
reader, I suggest that we should look at 
"It's done" from an absolutist's per- 
spective. "It's done" means it's ready 
to ship to the customer. Period. If you 
manage an engineering group, you're 
being evaluated on your ability to get 
quality products to market. As a devel- 
oper, you have to understand and work 
toward your boss's or boss's boss's 
needs. Anything less and you're a 
meaningless cog in a big wheel, some- 
one all too easy to dispense with during 
the next downturn. Our goal is not to 
create code or to build widgets — it's 
getting a product to market. "It's done" 
means the product is ready to go. 

To say "It's done, except for that last 
bit of optimization" is nothing more 
than a lie, as that last little task is prob- 
ably one of a dozen last little tasks, like 
testing the optimization, or updating 
the documentation, or going through 
the release procedure. Yet we know 
our supervisors want to hear "It's 
done" — sometimes, when a project is 
running months late, it's all they dream 
of — so we do a bit of "truth manage- 
ment" to get them off our back, to 
make them happier, or to relieve some 
of the pressure on us. Anything less 
than total objective honesty to those in 
charge is the act of a teenager who 
trades getting in ta-ouble today for 
much bigger problems tomorrow. 



Maybe I'm a 
pessimist, but the 
one thing we can 
reiy on is the 
perversity of 
nature: something 
wlii go wrong. 

We're all guilty of this dishonesty. I 
hear it everyday from developers who 
convince themselves that they are so 
close to completion that they're all but 
done, or who feel that one more night 
of heroic efforts will prove them close 
enough to being correct. We computer 
people are the worst sort of egotistical 
intellectuals. We believe — ^no, we 
know — that we're so good that we'll 
bail ourselves out of the disaster of the 
hour with a few all-nighters. 

Experience proves otherwise. 
Projects become late, panic mode 
starts, and sure enough, the system is 
eventually delivered. All of our 
promises and plans are for naught, 
though, as a thousand technical, man- 
agerial, and business problems thwart 
our best efforts. Maybe I'm a pes- 
simist, but it seems the one thing we 
can rely on is the perversity of nature: 
something always goes wrong. 

A Avise boss, on hearing "It's done," 
will question you extensively to under- 
stand the exact level of "done." A 
novice — or one working in the desper- 
ation of excessive hope — may believe 
"done" means "ready to ship," and 
start to make commitments that no one 
will live up to. 
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DONT DO BETTER 

Breaking this dysfunctional cycle is up 
to each of us. But simply promising 
ourselves to "just do better" is stiqiid 
and ineffective. 

With age (but less-than-anticipated 
maturity), it's interesting to look back 
and see how most of us form personal- 
ities early in life, personalities with 
strengths and weaknesses that stay 
largely intact over the course of 
decades. The embedded community is 
composed mostly of smart, well-edu- 
cated people, many of whom believe in 
some sort of personal improvement. 
But are we really successful? How 
many of us live up to our New Year's 
resolutions? 

Browse any bookstore. The shelves 
groan under the weight of self-help 
books. How many people are actually 
helped, or at least helped to the point of 
solving a particular problem? Go to the 
diet section — I think more diets are 
being sold than the sum total of excess 
pounds in the U.S. People buy these 
books with the best of intentions, yet 
many fail to achieve their goals. 

Our desires and plans for self 
improvement — ^at home or at the 
of&ce— are of the more noble human 
characteristics, but in reality, we fail — 
a lot. We commonly compensate by 
promising to ourselves to "try harder" 
or to "do better." That approach is 
rarely effective. 

Change works best when we change 
the way we do things. Forget the vague 
promises and invent a new way of 
accomplishing your goal. Plan to 
reduce your drinking? Exercise regu- 
larly? Develop a process that ensures 
you're meeting your goal. Don't just 
try harder, but change something basic 
and log the results daily. 

The same goes for improving your 
abilities as a developer. Forget the 
vague promises to read more books, or 
whatever. Invent a solution that has a 
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better chance of succeeding. Even bet- 
ter, steal a solution that works from 
someone else. The moral is to accept 
that we humans do a poor job of living 
up to our promises, and therefore we 
need to make grand, sweeping changes 
in order to improve. 

Check out Quality is Personal: A 
Foundation for Total Quality 
Management (Harry Roberts, Free 
Press, New York, 1993), a great book 
about finding new ways to do better. It 
turns the quality movement inside out, 
acknowledging our limitations, yet 
providing a framework for improve- 
ment despite human frailties. 

Unfortunately, in many circles the 
term "quality" has been Dilbertized to 
the point of total cynicism. So many 
fads, in management and elsewhere, 
are rammed down our throats that it's 
understandable when we cringe at the 
word "quality." Try to swallow your 
bile and read the book for useful con- 
cepts. After all, most of us are indeed 
seeking different sorts of quality — 
quality time with the family, quality 
work at the office that we can be proud 
of, and even a "quality" inner peace 
and contentment. I do think it's impor- 
tant to proactively work at improving 
every area of our lives, and 1 managed 
to pull some neat ideas about this from 
the book. 

Applying this concept to overcom- 
ing the "It's done" weakness, I think 
the solution is to develop a policy — 
and more importantly, a system — of 
total exposure. We need to recognize 
that "It's done" means different things 
to different people. 

Nothing beats a dynamic action list. 
It matters little if you use the latest pro- 
ject management software or a ruled 
paper pad; what's important is main- 
taining a list of things that must be 
done before you can utter those pro- 
found and soaked-in-meaning words 
"it's done" with firm resolve. 

No list is effective unless it's updat- 
ed in real time as the project changes or 
as you learn more. Planning is always 
incomplete, a continual source of acri- 
mony as the scope of a project 
changes. No matter — add the changes 



to the list, check off items as they're 
completed, and use the list as your 
scorecard, showing exactly which parts 
of a project are done and what remains. 
Expose it constantly to the entire pro- 
ject team, so everyone knows the pro- 
ject's status. Undisciplined project 
teams always drop the management 
tools — ^like the action list — ^as soon as 
they get too busy to keep these tools 
up-to-date. Ignore your management 
tools and disaster is inevitable. 

THE WRAP-UP 

Your action list must contain every- 
thing that is part of the project. End-of- 
project details are just as important as 
getting the code out, yet these details 
are often neglected. Rather than engag- 
ing in a mad scramble to clean up the 
mess in the microseconds between 
ending one project and starting the 
next, we can instead invent new 
^jproaches that leave no mess to clean 
up. 

Take documentation, for example. 
Somebody has to write that user manu- 
al before the product is ready for the 
customer. If all of the code is complete 
and the hardware works, but there's no 
manual, well, for all intents and pur- 
poses, the product doesn't exist. You 
can't ship it, so the development is still 
in that "spending money, unable to cre- 
ate revenue" status that so endears us 
to upper management. 

Granted, some documentation can- 
not be created until the product itself is 
ready to go, but much can — and should 
be — developed in parallel with the nor- 
mal engineering. In fact, I think it 
makes sense to rethink much of this 
process. Often a user manual is a much 
better project specification than the 
raw specs themselves. Doesn't it make 
sense, then, to write the manual first, 
before creating a line of code? Even 
better, the non-techie MBA types will 
get a better look at the final product 
through the customers' eyes when they 
read the manual, hopefully demanding 
changes before we start writing code, 
instead of a week before shipment. 

Another often-neglected area is ver- 
sion control. Some outfits defer the 



issue of controlling software until a 
release is imminent. Again, this is inef- 
ficient and silly. Before starting a pro- 
ject, implement a version control sys- 
tem (VCS). Once this was a difficult 
process; now it's almost trivial. 

Even a one-person shop needs a for- 
mal VCS. It's truly magical to be able 
to rebuild any version of a set of 
firmware, even a version that is years 
old. The VCS provides a sure way to 
answer those questions that pepper 
every bug discussion, like "when did 
this bug pop up?" A number of vendors 
provide these VCSs. Most of my expe- 
rience has been with Microsoft's 
Visual Source Safe, a Windows-hosted 
product that looks a lot like File 
Manager. 

A VCS insulates your source code 
from all of the developers. Under 
Microsoft's product, the code sort of 
disappears, rolled into a database of 
some sort. Scary stuff! You can get at 
the code only from the user interface 
provided by the tool, and cannot 
change code tinless you have the rights 
to do so. It controls the number of peo- 
ple working on modules, and provides 
mechanisms to create a single correct 
module from one that has been (in 
error) simultaneously modified by two 
or more people. 

Sure, you can cheat the controls on 
any VCS, as you can cheat your project 
activities list, but doing so is counter- 
productive. Maybe you'll save a few 
minutes of time up front, inevitably 
followed by hours or days of extra time 
paying for taking the shortcut. 

So save that time by never bypass- 
ing the VCS. Check modules in and 
out as needed. Don't hoard checked- 
out modules "in case you need them." 
Use the system as intended, daily, so 
there's no VCS cleanup required at the 
project's end. 

The same goes for project backups. 
Develop a system before you start that 
insures everything is backed up in a 
reasonable manner at frequent inter- 
vals. Don't plan on an raid-of-projeet 
backup and file cleanup. 

In my experience, one can't rely on 
individuals to be religious about back- 



ups. Some are passionately concerned 
and will do whatever is needed to have 
every file stored in more than one 
place. Others are concerned but incon- 
sistent in their efforts. I admit to being 
anal-retentive about backups. A fire 
that destroys all of the equipment 
would be an incredible headache; one 
that took the data would destroy the 
business. 

Yet, preaching about data duplica- 
tion and making draconian rules is 
ineffective. There's a bell curve of 
responses from people — some will 
save their files every night, while oth- 
ers forget or get distracted. Clearly, we 
need an approach that doesn't rely on 
people's good intentions. 

We keep all critical data (including 
the VCS database) on one server, and 
run a series of backups of that 
machine. All backups are automated, 
and other than changing the tape, 
require no human intervention. Tapes 
are great for archival storage, but are 
somewhat of a pain to use. When 
something goes wrong, like the person 
who changes the tapes goes on vaca- 
tion, or a tape fails, or any of a himdred 
other problems occurs, data could be 
lost. To combat this possibility, we 
keep a spare disk drive in the server 
just for daily and weekly backups. An 
automated job starts every night and 
copies all critical data to the spare disk. 
On Saturdays another copy is made to 
another hard disk, as added insurance. 

Extreme measures? Maybe. We 
don't lose data, though — ever. 
Computers fail and hard disks crash, but 
(to date) the data stays intact. And in the 
spirit of inventing a system that runs 
well despite human weaknesses, the 
process is automatic and imattended. 

With a VCS, though, people do have 
the ability to check out files and leave 
them out for long periods of time. 
Conceivably, their work on these files 
could be lost in a system crash. Short 
of rolling all network drives to tape 
(difficult, as most developers try to 
limit access to their shared drives), the 
solution we use is simply to have the 
VCS police monitor checked-out files. 
The project manager checks the status 



of files under his or her control (the 
VCS tells which files are checked out 
to which developers), and ensures that 
nolliing stays out too long. I'm still 
looking for a better solution to this 
potential problem. 

STANDARDS 

The quintessential software guru's 
observation, "Well, the code is work- 
ing, now I just have to comment it" 
signals the death of schedules and 
product quality. Leaving any part of 
the development process until the end 
will further fiizz the meaning of "It's 
done." 

Software that isn't created to a imi- 
form and rational standard caimot suc- 
ceed over the long term. Software just 
hacked together and shipped as soon as 
it seems to work is an open sore that 
will require maintenance, more than 
you ever expect, and possibly forever. 

The solution is to employ a software 



standard that is rigorously enforced. 
I've written about this solution before 
in ESP, and I received lots of corre- 
spondence fi-om people looking for a 
standard they could use. One such 
standard can be found at http:// 
www.microsol.com. I'm sure there are 
lots of others. If you have a standard to 
share with the rest of us, please let me 
know and I'll publish the URL here. 

Be honest with yourself and create 
decent code you're proud of, create 
reasonable action lists or project 
schedules, and always search for new 
ways to solve old problems. Make the 
phrase "It's done" mean something 
profoimd. 1^3 

Jack G. Ganssle is an old (well, not SO 
old) embedded hand. He helps compa- 
nies improve their engineering teams 
and analyzes embedded product 
designs. Ganssle enjoys contact — 
reach him at jack@ganssle.com. 
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Both C and C++ are designed to 
be machine-independent lan- 
guages that nevertheless remain 
reasonably close to the underlying 
machine architecture. To be portable, 
they must define clearly and precisely 
an abstract architecture that can adapt 
to a variety of real world computer 
architectures. Nowhere are clarity and 
precision more important than for the 
fundamental model of how to represent 
scalar data. To know what constitutes a 
proper int or double object, you must 
certainly know what's in a hyte. 

Embedded programs in particular 
often deal in tliat netherworld between 
raw storage and a properly up-and-run- 
ning "C machine." Embedded pro- 
grams often run on hardware that 
strains the bounds of compliance with 
programming language standards. It's 
important to know what you can and 
cannot get away with, and still enforce 
the basic guarantees required by C and 
C++. 

Over the years, the C and C++ stan- 
dards committees have sharpened their 
collective understanding of the storage 
model shared by the two languages. 
My goal here is to summarize that 
abstract model, including some aspects 
tot have only recently become clear. 

C was bom on the DEC PDP-1 1. In 
short order, it was moved to a variety 
of other computer architectures. Most 
of those early machines supported 
byte-level addressing of 8-bit bytes. 
They performed integer arithmetic in 
two's complement with no overflow 
trapping. The primary difference 
among those early machines was in the 
order of bytes within multibyte scalar 
objects. Needless to say, this common- 
ality of basic features materially eased 
the problems of porting C among 
machines. 

Nevertheless, C soon appeared on 
machines that didn't follow this agree- 
able recipe. Sopie machines had word- 



When the ANSI 
standardization 
effort began for C, 
few architectures 
existed that didn't 
support some 
flavor of G. 

oriented architectures, where the fur- 
ther subdivision into bytes was both 
tiresome and arbitrary. Eight-bit bytes 
ware not always the obvious choice, 
particularly for a machine with, say, 
36-bit words. Some machines were 
less tolerant about integer arithmetic. 
They would poorly support C's brand 
of unsigned arithmetic, or they would 
have codes for -0 that sometimes 
changed to +0, and sometimes did not. 
For these more diverse architectures, 
knowing how best to implement C was 
difficult. 

By the time the ANSI standardiza- 
tion effort began for C in 1983, few 
architectures existed that did not sup- 
port some flavor of C. A diversity of 
implementations had arisen, some 
inevitably mapping C to the underlying 
hardware in different ways. One of the 
important early questions for the C 
Standard was whether any of these 
existing implementations had stretched 
the unwritten rules too much. Put 
another way, the committee had to 
determine the invariant properties of 
an abstract "C machine" aeross 
computer architectures. 

Many years have passed since that 
first ronnd of questions were answered. 



The decisions made then by committee 
X3J11 (now just Jll) have held up 
rather well, though they have enjoyed 
occasional refinement. Here is a brief 
summary of the C memory model, vin- 
tage 1984. 

First, it was clear that type char was 
in some sense elemental. A common 
idiom for copying an arbitrary object 
of type T ftom x to y was: 

char *p = (char *)&x, *q = (char *)&y; 
char *pend = p + sizeof (T); 
while (p < pend) 
*p++ = *q++; 

Modulo various optimizations, that 
idiom is still widely used in C pro- 
grams. Committee X3J11 essentially 
took the correctness of this idiom as 
axiomatic and worked backwards. 
What must be true for the idiom always 
to work properly? Each line of the 
idiom expresses a different constraint: 

■ The first line says that a pointer to 
an arbitrary object can be converted 
to a pointer to char without loss of 
information 

■ The second line says that an object 
of type T is exactly as large as an 
array of sizeof (T) elements of type 
char 

■ The third line says that it is permis- 
sible to compare a pointer within an 
array to a pointer just beyond the 
end of the array 

■ The fourth line says that copying 
the value of each char in the (con- 
ceptually) overlapping array suf- 
fices to copy the value of the object 
of type T 

Note that these constraints apply 
both to the addressability of objects 
(constraints 1 and 3) and their repre- 
sentation (constraints 2 and 4). Earlier 
programming languages were less 
ambitious in defining the effects of 
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pointer arithmetic and aliasing (treat- 
ing the same storage as two or more 
different types of objects). Hence, C 
had to invent semantics that it couldn't 
inherit from its predecessors. 

The copy idiom has two other 
important guises. The idiom is impHc- 
itly buried in such library functions as 
memcpy and memmove, declared in 
<string.h>. It is also implicitly at work 
when reading and writing binary files, 
such as with f read and furite, declared 
in <stdio.h>. In all cases, it is funda- 
mental to C that the value of an object 
can be copied — even out to a file and 
back — ^by treating it as a sequence of 
objects of type char. 

There's more to a data representa- 
tion than copying bits about. An imple- 
mentation has to assign values to the 
different bit patterns. It also needs to 
provide some assurance, for writing 
portable code, that a given object type 
supports an adequate range of values 
as well. So X3JI1 also found itself in 
flie business of decreeing constraints 
on representations and minimum 
ranges for the scalar types of C. You 
can find many of these decisions 
memorialized in the headers <float.h> 
(invented by the committee) and <lim- 
its.h> (borrowed from Posix). 

An unsigned integer is the easiest to 
describe. It must be represented as a 
weighted binary code. In other words, 
A'' bits always represents the inclusive 
range of values zero (all zero bits) 
through 2^-1 (all one bits). Moreover, 
the committee set the following mini- 
mum values of N for the unsigned inte- 
ger types: 

N Type 

8 unsigned char 

16 imsigned short 

16 unsigned int 

32 imsigned long 

A signed integer has a little more lat- 
itude. It, too, must be represented as a 
weighted binary code, but with a dif- 
ference. One of the N bits serves as a 



sign bit. If that bit is zero, the remain- 
ing iV- 1 bits represent positive values 
by the same rules as for unsigned inte- 
gers. If the sign bit is set, however, 
several encodings are permissible. All 
must have distinct codes for the inclu- 
sive range of values -(2^ - 1) through 
-1. The remaining code happens to 
represent: 

■ -(2N) in two's complement encod- 
ing 

■ -0 in one's complement 

■ -0 in signed magnitude 

All are permissible encodings for 
Standard C. 

Floating-point arithmetic is even 
more tolerant. Within broad limits. 
Standard C pretty much tolerates what- 
ever the underlying architecture does 
in the way of floating-point arithmetic. 
This is such a huge topic that I won't 
begin to probe its depths here. It war- 
rants at least another essay of its own. 

The same goes for pointers. All I'll 
say here is that Standard C tolerates a 
number of different representations for 
pointers, even witiiin a single imple- 
mentation. One value of each represen- 
tation must represent a null pointer — 
designating no object that you can 
declare or allocate within the program. 
But a null pointer need not be all zero 
bits. It might be a good idea, for other 
reasons, to make all zero bits stand for 
a null pointer, but Standard C doesn't 
require this nicety. (And yes, floating- 
point representations have the same 
latimde. Having ail zero bits doesn't 
necessarily r^re^t a floating-point 
zero.) 

CHALLENGES 

What I've just described is essentially 
what was captured in the C Standard. It 
wasn't long, however, before people 
began to poke at the comers of the tidy 
little model set out above. Computer 
architectures are endlessly diverse, it 
seems. And sooner or later someone 
will want to put up something resem- 
bling C on practically every piece of 



hardware that can execute a stored pro- 
gram. Here are some of the issues that 
have caused a few heated discussions 
among those who would interpret the 
C Standard. 

Perhaps the most serious is the very 
notion of "byte" itself. The C Standard 
is fairly glib about confusing three dis- 
tinct concepts: 

■ a byte, the elementary unit of stor- 
age 

■ type char, the smallest of the scalar 

types 

■ a character, which is a code value 
that stands for a member of some 
character set 

Within a C program, the murkiness 
isn't too froublesome. A char object 

does indeed occupy one byte. That's 
because the sizeof operator officially 
counts bytes, and sizeof (char) always 
has a value of one. And a char object 
can, by definition, store the codes for 
aU the characters in the basic C charac- 
ter set, and then some. 

Of course, it doesn't help that even 
the C Standard has to talk about multi- 
byte characters and wide characters as 
well as (single-byte?) characters. Both 
the C Standard itself and the more 
recently approved Amendment 1 have 
rightly been accused of fuzziness in 
distinguishing all flie various flavors of 
characters now kicking about. But 
that's not the issue here. 

The real problem is that the outside 
world has settled on a fairly sharp def- 
inition of a byte. It's what ISO stan- 
dards tend to call an "octet," or group 
of eight bits. The world, as we all 
know, is paved with 8-bit UARTs, 
communication channels, and magnet- 
ic media. An implementation that can't 
traffic in octets is doomed to life in a 
tiny ghetto. Indeed, such was the fate 
of the ambitious C Machine, sold for a 
time by Bolt, Beraneck, and Newman. 
tkit machine's ov^fc bytes caused 
no end of grief 

Other machines are still viable 
despite having oversize bytes. A word- 
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oriented processor, for example, might 

want to avoid the inefficiencies of byte 
packing and impacking by defining a 
byte as big as a word. Standard C does 
indeed permit: 

sizeof (char) 

= sizeof (short) 
= sizeof (int) 
= sizeof (long) 
= 1 

so long as the minimum size rules I 

gave above hold true. That's all well 
and good, but what do you do about 
reading and writing more conventional 
files? 

You can indeed make a conforming 
C implementation with these con- 
straints, but at a cost. Text files have 
sufficient latitude to permit reading 
and writing of octets, regardless of 
internal byte size. Binary files have to 
deal exclusively in words — comman- 
deering a sufficient number of octets to 



represent each word exactly. If a word 

is not a multiple of eight bits, then you 
lose a few bits on the way in and add 
padding on the way out. This isn't a 
transparent channel to another imple- 
mentation, but it can serve as a trans- 
parent repository for objects in local 
programs. 

The real problem is more pragmatic. 
Like it or not, the world is full of C 
code written with additional con- 
straints m mind. Many programs mis- 
behave unless: 

sizeof (char) < sizeof (int) 

regardless of what the C Standard says. 
Many programs assume that a byte is 
indeed an octet. The cachet of official 
conformance may be useful for an 
unconventional implementation, but 
fliat doesn't guarantee easy access to 
supposedly portable C code. 

More interesting are implementa- 
tions that insist on leaving "holes" in 



integers. Consider an architecture with 
36-bit words and only signed integer 
operations. The best performance 
might be obtained by representing 
unsigned long with 32 to 35 magnitude 
bits, keeping clear the sign and any 
other unused bits. Does tiiis practice 
conform to the C Standard? 

If you buy that, then consider an 
architecture that has only floating- 
point arithmetic. The best performance 
here might be obtained by representing 
unsigned long with 32 or more mantis- 
sa bits and an exponent that ensures 
that the mantissa looks like an integer. 
Does this conform? 

I've even been asked about an archi- 
tecture that leaves explicit holes inside 
an integer. Bit 23, say, may be weight- 
ed 2^3 and Bit 30 may be weighted 224. 
Bits in between are weighted zero. 
Whatever you may think of the aes- 
thetics (or ancestr\') of the architect, 
such machines have been made and 
have attained some degree of commer- 
cial importance. Does this bizarre prac- 
tice still conform to the C Standard? 

It turns out that tiie answer in all 
three cases is yes. The C Standard 
failed to make it clear, but an imple- 
mentation can indeed distinguish 
between the object bits that make up a 
representation and the value bits that 
contribute to its stored value. It's okay 
to have object bits that aren't value 
bits, at least in many cases. They don't 
even have to be in any particular ordar, 
as long as the aritimietic comes out 
right. 

This latitude is a bit more con- 
strained for type char, however. This 
type can't have any unused object bits 
in places that would overlap value bits 
in another object type. Otherwise, the 
copy idiom we discussed would fail. 
Note that saying that type char can 
have no unused object bits is too strong 
a statement. Many memories have a 
parity bit on each byte, which C toler- 
ates quite nicely. 

A still more interesting issue has 
been recentiy raised. Type char can 
have the same representation as either 
unsigned char or signed char. In the lat- 
ter case, several encoding rules are 
acceptable, as previously described. 
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Two of them, ones complement and 
signed magnitude, have a representa- 
tion for -0. So what happens if the ven- 
erable copy idiom runs on such an 
implementation, and the hardware 
likes to convert -0 to +0 at the drop of 
a hat? From all appearances, the loop 
no longer transparently copies object 
bits. 

Evidently, a^earances are correct, 
at least in principle. Few, if any, 
machines actually represent type char 
this way. Those machines that do may 
well copy bytes transparently anyway. 
Nevertheless, it is mildly rash for the C 
Standard to talk so glibly about copy- 
ing arrays of char. Instead, the standard 
should emphasize that arrays of 
unsigned char are the proper aliases to 
use for copying objects in C. 

While discussing this point some 
time ago, X3J1 1 considered still anoth- 
er related issue. I stated earlier that 
signed integers have one unencum- 
bered bit pattern. Sometimes it stands 
for a large negative number, some- 
times for -0. But are those the only 
choices? 

In particular, floating-point repre- 
sentations can have a host of NaN (Not 
a Number) codes. Some of these codes 
can even trigger a hardware trap when 
accessed from an object (these are 
"signaling NaNs," in contrast to "quiet 
NaNs"). Similarly, some machines can 
detect and trap on invalid pointer val- 
ues. Should integers be exempt from 
this treatment or are they fair game 
too? A system with aggressive debug- 
ging support might want to add such a 
capability, while a program that plays 
with uninitialized integers might not 
want to. In the interest of maximum 
portability, everyone should know 
what is permitted. 

You can argue it either way, and we 
did. In the end, however, the sentiment 
among X3J11 members was that 
signed integers can indeed have a NaN 
code. Note that this license is not 
granted unsigned integers. All value 
bits participate in the value. Of course, 
a debugging compiler might still 
choose to tag uninitialized unsigned 
integers in sonie way. And some users 
might stiU welcome a report that an 



uninitialized unsigned integer was 
accessed. Conformance is often of sec- 
ondary importance when you're chas- 
ing a nasty bug. 

C++ CONSTRAIMTS 

I shall end with a few comments on 
additional issues raised by C++. 
Perhaps the most important issue is 
that the copy idiom isn't always appro- 
priate. Some objects in C++ are indeed 
containers for values. Make a copy of 
their bytes and you have a valid copy 
of their value. But other objects don't 
suffer bitwise copying as well. They 
may store reference counts or pointers 
to other parts of the same object. In 
such cases, copying is best left to 
smarter agents. That's why you can 
define specific copy constructors and 
assignment operator overloads for 
classes in C++. 

An object can also have a dynami- 
cally determined type. Put simply, you 
can have a pointer to an object and not 
know whether it is truly an object of 
the specified base type or of some 
derived type you don't even know 
about. In practical terms, each such 
object must store a pointer to a table of 
information. That table ■ is usually 
called a "virtual table," or v-table, 
because its principal function is to 
store an array of pointers to the virtual 
functions that nii#it be overriddm in a 
derived type. 

In more practical terms, such an 
object requires a bit of initializing, 
even before its constructor is called. 
Otherwise the programmer would be 
saddled with all sorts of caveats about 
taking addresses and calling virtual 
fimctions while the constructor exe- 
cutes. And that situation calls for fur- 
ther refmements of the memory model. 
Some distinguishable states are: 

■ The address of the object is repre- 
sentable 

■ The object is ready to be coi^truct- 
ed 

■ The object has been successfully 
constructed 

H The object has been destroyed 

■ The address of the object is no 
longer representable 



By contrast. Standard C seldom 
worries about more than the first and 
last states of an object. 

The C++ Standards committees, J16 
and WG2 1 , have refined these issues to 
deal with the greater precision required 
by the C++ memory model. The dis- 
tinctions are important because it is 
easy for programmer-supplied code 
that can access an object in all of these 
states to be executed. Unfortunately, 
not all the ground rules have been 
spelled out in the past. Some C++ code 
doubtlessly works only because of 
implementation peculiarities, not for 
any sound theoretical reasons. 

A particularly delicate area is the 
business of programmer-supplied ver- 
sions of operator new. Consider that the 
only real source of unconstructed 
objects is the library function malloc 
and its ilk, all declared in <stcDj.b.h>. 
Any other storage in a C++ program 
has already had some object construct- 
ed on it. (See "Turtles and Overcoats," 
ESP, April 1997, p. 100.) 

Can you destroy the old object, then 
construct the new one in the same 
space? Or can you simply construct the 
new object, knowing that the old object 
needs no destroying? Can you double 
construct an object safely? Serious 
C++ code indulges in all these prac- 
tices, but no guidelines have yet been 
laid down to say whether any or dl are 
safe. 

As a result, I venture to say that the 
memory model that began with C will 
continue to be refined. We know a lot 
more about how to structure storage 
than your basic assembly language 
jockey, but we also have more to learn. 
At stake is the safety of optimizations 
and the ultimate portability of large 
quantities of code, in both C and C++. 
This essay is merely an interim report 
on a work in progress. IM3 

P.J. Plauger is President of 
Dinkumware, Ltd. and author of the 
standard C++ library shipped with 
Microsoft Visual C++. His latest 
books are The Draft Standard C++ 
Library and Programming on Purpose 
(three volumes), both published by 
Prentice Hall in Englewood Cliffs, NJ. 
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qo to frane_B, 0: go to trig. 



Real-Time 
Microprocessor 
Development 
Systems 

EmJL166-PC 




EMUL166-PC FEATURES: 

•Supports Siemens' CI 66, CI 67CR, 

C167SR, C165, C163, C161 

and SGS Thomson ST1 series. 
• Hosted on PC's or workstations. 
•High-level support for Keil and 

Tasking C-compilers. 
•Connects to PC through 

standard printer port or 

through plug-in board. 

„ ^. I ^ , , MICROSOFT 

•Optional trace board. windows/'95 

COMPATIBLE 





Argenlina 54 1 312-1079/9103 , Australia (02) 554 1873, Austria 0222 277 20-0, Benelux (078) 681 61 33 
Brazil (01 1) 453-5588 , Canada 514-689-5889, China -e86-1 0-2059495, Denmark 43 44 60 10 
Finland 90-8S7 33 330 , France (1 ) 69 41 28 01 , Germany 07043/40247 , Great Britain 01 962-733 1 40 
Greece ■f30-1-924 20 72, India (0212)412164, Israel 03-6491202, Italy 02-49-82-051 , Japan (03) 3405-0511 

NOHAU INTERNATIONAL 

Korea (02) 784-7841 , New Zealand 09-3092464, Norway 22 67 40 20, Portugal 01 421 3141 
Romania 056 200057, Singapore +65 749-0870, S.Africa (021 ) 234 943, %iain 493) 291 76 33 
Sweden 040-59 22 00, Switzerland 01 -745 1818, Taiwan 02 764021 5, Thailand (02) 668-5080 



To learn more, call (408) 866-1820 for a product 

brochure and a FREE Demo Disk. The Demo can 
also be downloaded from our web site- 
http^/www.nohau.com 




For more information via your Fax, call our 
24-hour Fax Center at (408) 378-2912. 

noHau 

CORPORATION 

51 E. Campbell Avenue 
Campbell, CA 95008-2053 
Fax. (408) 378-7869 
Tel. (408) 866-1820 
Email: sales@nohau.com 
web: http://www.nohau.com 

Support also available for: 
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HMI's SPS-2000 Series PowerPC 
development tools take emulation 
technology to a whole new level. 
Hne in-circuit emulators, they change 
easily and economically to support 
most PowerPC variants from Motorola 
and IBM via a simple, low-cost pod 
change. And they 
have the following 
standard performance 
features that make 
them the industry's 
most powerful 
microprocessor 
de\'elopment system: 
• Hardware-based 
non-statistical soft- 
ware performance 
analyzer. •Ethernet 
interface for high- 
speed connectivity. • High-speed 
overlay memory for code download, 
mappable via chip selects. • Shadow 
RAM for real-time data variable/ 
memory monitoring. • 128K, deep 
trace buffer configurable in up to 
8192 separate buffers for windowing 



events of interest. • 8-level trigger 
and breakpoint sequencing logic. 
• Hme-based delays for break and 
trigger points. • Direct variable editing 
in watch windows. • Native GUI 
support from multiple host platforms 
(Windows 3.1x/95/NT, Sun, HP) using 
SourceGate II, 
HMI's powerful 



HMI ALSO PROVIDES SUPPORT 
FOR THESE PROCESSORS. 



source -level 
debugger that 
is a common 
user interface 
for all HMI 
products. 
• Multiple 
object file 
format support. 
Use your com- 
piler of choice! 
• Unlimited CodeView windows allow 
breakpoints to be set across multiple 
modules displa^'ed in source, assembly, 
or a combination of the two. • Can 
be operated stand-alone with no 
target system required or can be put 
in-circuit in place of the processor. 
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• Free lifetime 

technical support (no 
costly yearly support contracts 
to worry about — ever!) 
Interested? Call or write and we'll 
be happy to send you more detail 
ed information. Can't wait? Visit our 
Web Site at http//www.hmi.com/ for 
instant access to our SPS-2000 data 
sheet and information on our $199P° 
Background Mode Debugger! 



HUNTSVILLE MICROSYSTEMS, INC, 

P.O. Box 12415 
Huntsville, AL 35815 
M (205) 881-6005 
Fax: (205) 882-6701 , 
sales@liiTii.com , 
http://www.hmi.cora/ 
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